What manual cleanup steps are required after a failed Meteor upgrade to prevent version conflicts?

Goal: ascertain whether a failed Meteor package or platform upgrade leaves the node_modules directory and the .meteor/local build cache in a state that can cause version conflicts when the upgrade is retried.

Constraint: Meteor records the exact versions of all packages in .meteor/versions and provides commands such as meteor reset and meteor update --release to restore consistency, but it does not automatically remove or clean the auxiliary directories after an interrupted upgrade.

Uncertainty: it is unclear if retaining the existing node_modules and .meteor/local folders after a failure introduces incompatible package versions or stale compiled assets that must be cleared manually.

Does retaining the existing node_modules directory after a failed upgrade lead to version mismatches? Should the .meteor/local directory be deleted before attempting the upgrade again? Is restoring .meteor/versions and running meteor reset sufficient, or is additional manual cleanup required?