Keep the startup update splash up until the restore window reveals

During a startup update check that ends in a skip (no install), the update splash is destroyed as soon as the normal UI is opened. When the boot is a startup-restore boot (autoLaunchOnStartup set to an instance), the chooser host window is created hidden and only revealed once the instance launch takeover is ready (or the 10s reveal backstop fires). This leaves a few seconds where no window is visible: the splash is gone and the restore window has not revealed yet.

This is cosmetic only. A live window exists, so window-all-closed never fires and the app stays alive. The blank interval is also identical to what a normal restore boot (without a pending update) already shows by design, since the window is deliberately kept hidden until its takeover is up so the dashboard never flashes.

Proposed improvement (deferred from PR #1473 review):

- Change the splash-destroy condition from "another live window exists" to "another visible window exists".
- If the only other window is alive but hidden, attach a one-shot show listener on it and destroy the splash at reveal, plus a backstop timer (~15s, past the 10s reveal backstop) that destroys the splash regardless.
- Every splash-destroy point must re-evaluate the last-window guard at fire time: destroying the splash while it is the last window fires window-all-closed and quits the app, which is the original update-loop bug. In particular, if the hidden window is destroyed before ever showing, the backstop must keep the splash up rather than quit.
- Add a third splash copy state (e.g. "Starting Comfy Desktop...") swapped in once the update check resolves as skip, so the splash does not keep saying "A downloaded update is being verified" while the app is actually launching the restored instance. The render-chaining pattern in updateSplash.ts already supports this.

Raised by CodeRabbit review on PR #1473; deferred there because the fix is complete without it and the extra splash lifecycle complexity was not worth blocking the loop fix.

Start in updateSplash.ts and trace every point where the splash is destroyed after the startup update resolves as skip. Check how the hidden chooser host window is revealed and how the existing render-chaining pattern handles splash copy changes. Done means the splash remains until a visible restore window appears or the backstop fires, rechecks the last-window guard at each callback, and shows startup wording after the skip.

Written by the indexing model from the issue text.