Restoring a snapshot while ComfyUI is running feels weird

ComfyUI is taken down while it happens, but is not booted up or told to the user that it is offline. We need to come up with something that is clear. We are a bit inconsistent right now about when ComfyUI autostarts after an operation or not.

Additional issues - if --feature-flags were detected for launch, launching after restoring to a version that does not support a that detected feature-flag (not sure if extends to startup args) will cause the launch to still try to use those startup args. It kept doing htis for me until I rebooted Comfy Desktop. We should make sure the feature-flags/similar that are detected per ComfyUI version work for both updates and downgrades in general.

Start by tracing the snapshot restore flow and the ComfyUI launch lifecycle, then compare how updates and downgrades handle detected feature flags and startup arguments. Done means the offline state is communicated clearly, autostart behavior is consistent, and version-incompatible flags or similar arguments are not reused after restoring.

Written by the indexing model from the issue text.