Restore the running strip after a restart, not just the Close Apps button

[Shieldxx]

Follow-up to #673, which is closed by the per-game button. This is the other half: the strip.

Why this exists as its own issue

#673's decision of 2026-08-04 scoped it to the button and assigned the strip to #794 ("leave the strip alone"). The Codex-found second route recorded on 2026-08-18 then added an acceptance criterion that widened it: "restores the strip and the Close Apps affordance without a relaunch."

Those two cannot both be satisfied by one PR, so the button shipped and the strip is tracked here rather than being quietly dropped. The affordance now returns on both routes (restart and the process-tracking toggle cycle), because the closable set is rebuilt from the store. The dots do not: they come from getTrackedRunningApps, which is gated on adoptedOrLaunchedGameKeys, and nothing puts the key back into that set.

Why the obvious fix is still ruled out

Adopting a game key because a configured companion is running remains unsafe for the reason in #673's Fix section: the adopted key feeds the aggregate running status that drives row highlight, sorting and canRelaunch, so every profile with SimHub enabled would read as "running" whenever SimHub is up. It is also intent-blind, which is the objection #794 settled: it cannot tell "left over from our session" from "autostarts with Windows".

The direction that is not intent-blind

Remember ownership instead of inferring it. SimLauncher knows it launched SimHub under the AC profile; it just forgets at exit.

• Store: one new schema property, { [gameKey]: Array<{ path: string; launchedAt: number }> }. Paths and timestamps only. Never PIDs (Poll path cache: a PID reused within one tick keeps the old executable path #847), never name-scoped entries (they have no path to verify and would reintroduce the Exe-name collision: same-named exe from another path fakes already-running, then kill reports bogus running-as-administrator #674 collision class), never the game exe.
• Written: at successful companion spawn, where runningProcesses is written. Transition-driven, never per scan tick.
• Read: the file is a question, not an answer. At startup, path-verify each record with the primitive built for Exe-name collision: same-named exe from another path fakes already-running, then kill reports bogus running-as-administrator #674 and re-establish ownership only on a hit, feeding verified keys into adoptedOrLaunchedGameKeys as a fourth membership source. Do NOT re-seed runningProcesses: its process: ChildProcess is required and the kill paths assume a live handle a restarted app does not have.
• Pruned: on verified exit, on successful kill, on a startup re-check miss, and when the path leaves the profile's trackable set on a config change.

The trap that decides whether this is correct

A reboot ends our processes by definition. User reboots, SimHub autostarts, SimLauncher starts, finds a record, path-verifies it and re-adopts a process it never launched this boot. Path verification proves "something runs at this path", never "the thing we launched still runs". So drop any record whose launchedAt predates the current boot, derived from os.uptime(). A rare false drop fails safe, back to today's behaviour for one session.

Second trap: #591. Tracking-off must HIDE the surfaced state at read time and must not delete the record, or toggling back on cannot restore it and the acceptance above fails again. Same one-way-door lesson already paid for on the elevated handoffs.

Acceptance

• After a tray Quit and reopen with companions still running, the strip shows them and Close Apps is primary, with no relaunch.
• Turning process tracking off hides them within one publish and turning it back on restores them, with no relaunch.
• A record whose launchedAt predates the current boot is dropped without adopting, even when something is running at that path.
• A record with nothing at its path is dropped on the first succeeded scan.
• A failed tasklist read makes no adoption decision and prunes nothing (fix: suppress misleading kill-failed toast when launched exe is gone (#390) #399).
• Two profiles owning the same companion path both re-own it, and closing from either clears both.

[Shieldxx]

The button already answers this question differently, and this issue has to reconcile them

Surfaced while deciding whether to hold the 1.2.0 tag for this issue. Verified against getClosableLaunchedAppGameKeys in kill.ts.

The close button that shipped in #853 is not ownership-gated. Its final pass walks every configured companion target, and for any that is running at its configured path and is not already launch-owned, it adds every profile that configures it to the closable set. No record of who started it is required, or consulted.

That is deliberate and matches the decision of 2026-08-04 (ambient closable state gets a secondary control), and the code says so. But it means the intent-blind inference this issue rules out for the strip is already the shipped semantics for the button. Concretely: after a reboot where SimHub autostarts with Windows, every row whose profile enables SimHub offers to close it, for a process SimLauncher never launched.

The difference that makes it acceptable there is the human: the button is an explicit click, and closing a companion is recoverable. The affordances this issue would feed are implicit, which is why ownership matters for them.

So this issue has one more decision to make than it currently states. When ownership memory lands, either:

1. the button becomes ownership-gated too, which is a behaviour regression against After a SimLauncher restart with the game closed, running companions vanish from the UI and the Close Apps affordance disappears #673: the leftover companions of a profile whose ownership record was legitimately dropped (previous boot, a config change that moved the path) would go back to being uncloseable from the app, which is the exact complaint After a SimLauncher restart with the game closed, running companions vanish from the UI and the Close Apps affordance disappears #673 was filed for; or
2. the button keeps its ambient rule and the strip gets the ownership rule, and the app permanently holds two different answers to "may I close this?", one for what it shows and one for what it does.

Option 2 is probably right, but it should be chosen rather than arrived at, and the acceptance list should say which, because a reviewer will otherwise read the mismatch as a bug.

Related: #852 (the control does not say what it will close) gets sharper under option 2, since the button would then act on a superset of what the strip displays.