A bridge browser launch that cannot begin is reported, not a daemon crash (#1332)

[suleimansh]

Rom's Linux try on #1332: picked "A browser the daemon runs", the panel said only "The bridge browser is off." — because the daemon had exited.

What

The daemon mints the bridge token once, at boot, from the bridge preference as it stood then (daemon.ts:143). Switch the bridge on and pick the daemon's browser in the same sitting, and the launcher throws its "restart first" error synchronously inside start(), before any handler is attached. void bridgeBrowser.start() made that an unhandled rejection, which ends the process (reproduced: Node 24, exit 1). The dashboard kept its last reading, "off", since every read after that fails quietly.

• bridgeBrowserOwner.start() calls the launcher inside a promise executor: still synchronous (its first step is readable at once, which four existing tests rely on), but a throw is now a failed launch — stopped, with the reason, logged as "could not start" — the same path a launch that fails on the way takes.
• The daemon's launcher says precisely what to do: the browser bridge was switched on after the dashboard started — restart the dashboard, and the browser launches on its own, or turn the browser bridge on, then restart the dashboard when it is off. It reads the preference at launch time to tell the two apart.
• The settings line reads "The bridge browser is not running: ." with its Restart button — it now covers a launch that never began, where "stopped" was wrong.

The restart requirement itself stands: the bridge routes are also mounted only at boot. That is a separate wart, not this fix.

Verified

Full suite green (1648 node + 864 dashboard; 1 new test). Broken on purpose in the compiled output — the plain launch(...) call restored — the new test dies with the launcher's error instead of reading stopped.

Specs: bridge-browser.SPEC.md (the launch that cannot begin), BridgeBrowserSettings.SPEC.md (not running, not stopped), both test specs.

🤖 curated · Fable 5, effort high