runtime-host: intermittent 'stopped responding during startup' after a Windows upgrade over an existing profile

On the Windows upgrade-lifecycle check, the app installed by an upgrade intermittently fails to start: its own stderr reports

```
[runtime-host] fatal: Error: Runtime Host stopped responding during startup
at runtimeHostStartupError (…/app.asar/node_modules/@maka/runtime-host/dist/client/startup-error.js:25:20)
at RuntimeHostDesktopManagerImpl.connect (…/dist/main/runtime-host-desktop-manager.js:317:19)
at async RuntimeHostReconnectLifecycleImpl.start (…/reconnect-lifecycle.js:62:45)
```

and the renderer never mounts, so the packaged smoke times out.

**Observed:** [run 32324991998](https://github.com/apache/maka/actions/runs/32324991998/job/96295423079) on #3241, step `Exercise pinned-version upgrade and uninstall`. The sequence that failed: the pinned 0.1.9 baseline installed and verified clean → upgraded to the current 0.1.11 build → the upgraded app's Runtime Host stopped responding during startup. The standalone smoke of the same 0.1.11 build passed minutes earlier in the same job, so the build starts fine against a fresh profile.

**What makes the upgrade path different:** the lifecycle deliberately reuses one isolated HOME and user-data directory across both versions — that is the point of an upgrade test — so the 0.1.11 Runtime Host starts against whatever state 0.1.9's run left under that HOME (host socket/lock/config). Whether the hang is caused by that leftover state or is an unlucky cold-runner slowdown is exactly what the log cannot yet say: the fatal is a client-side startup timeout, and the Host process's own stderr is not captured in the verifier output.

**Attribution note:** this surfaced through #3241's new CDP diagnostics (the app wrote `DevToolsActivePort`, the poll named the bound port, and the endpoint never answered — which is what pointed at the main process rather than the port plumbing). Some of the historical `did not expose CDP within 30 seconds` failures in this step may share this cause, but that cannot be established retroactively from the old logs.

**Suggested next steps:**
1. Capture the Runtime Host child's stderr (or its log file) into the lifecycle verifier's failure output, so a startup hang is attributable to the Host's own last words rather than the client's timeout.
2. Reproduce locally: install 0.1.9's profile state, then start a current build against it, in a loop.
3. If leftover state is the trigger, the fix likely belongs in Host startup's handling of a predecessor's socket/lock remnants.

Not caused by #3241 (verifier-only changes); filed separately so the product-side question is trackable.