Failed desktop update can restart a tray-stopped runtime

[Ingwannu]

Summary

After a user stops the desktop-owned runtime from the tray, a later update attempt that fails can turn supervision back on and start a runtime the user explicitly left stopped. This shipped in merge train #5998 (5744e7a19f).

Deterministic state transition

1. Tray Stop runs begin_stop/finish_stop, leaving the coordinator Idle with wanted=false; successful drain also releases AppState.
2. Update preparation claims a coordinated restart and observes no owned runtime, so it reaches Drained.
3. Installer failure calls abort_restart. It unconditionally sets wanted=true.
4. after_install_failure sees that the phase had been Drained and starts Mode::Recover.

The previous manual-stop intent is lost even though the update never installed. Existing tests construct a fresh coordinator whose runtime is wanted, so they prove recovery for the normal running case but omit the stopped case.

Expected fix

Remember whether the runtime was wanted before the coordinated restart claim. A failed update should return to that prior intent: recover only when the update stopped a runtime that was wanted, and remain idle/stopped when it was already unwanted. Quit ownership and successful-update behavior must remain unchanged.

Required regressions

• running/wanted + drained + install failure restores supervision and requests one recovery;
• tray-stopped/unwanted + no-owned-runtime/drained + install failure remains idle with supervision disallowed and requests no recovery;
• failed/unknown drains keep their current no-duplicate-start behavior;
• a user quit is never converted back into a running app.

[lidge-jun]

Fixed on dev by #6041, carried in #6059 (merge 8923ad9835).