fix(windows): say what to do when the Store tray app cannot be spawned

[ozymandiashh]

Fixes #1520.

What happened

With the desktop app installed from the Microsoft Store, codeburn menubar found the Store-packaged tray exe under C:\Program Files\WindowsApps\... and spawned it directly. Windows denies that from a console outside the package's app container, so the spawn failed with EPERM — and because launchWindowsApp was fire-and-forget (console.error on the error event, return immediately), the run died in the CLI's catch-all as a cryptic Menubar install failed: spawn EPERM, while the Store route had already printed its "nothing to download" narration as if the launch were about to work.

What changed

• launchWindowsApp now answers for its own spawn: it returns the error message on a failed spawn (error event) and resolves null once the process is up (spawn event, then unref). On a failed spawn Node never emits spawn, so the two cannot both fire — verified with a probe against the real uv_spawn failure path (ENOENT/EACCES, same path as Windows EPERM).
• New awaitLaunch helper normalizes the launch hook's result — sync-void test hooks from before the change still read as success, an empty string counts as success, a throwing hook is caught and becomes the message.
• Store route: a failed spawn now throws with an actionable message — Start CodeBurn Menubar from the Start menu instead; the Store copy cannot be launched from a console. — instead of the generic install failure. The Start-menu tile is the activation the package actually allows.
• The two .msi routes (already-installed launch-only, and post-install) report the launch error with a clarifying suffix — (the install itself succeeded; start CodeBurn Menubar from the Start menu if it did not appear) / (nothing was reinstalled; ...) — so a launch that could not happen does not read as an install that did not.
• The --quit signal in stopRunningMenubar logs a spawn failure instead of dropping it, and still does not abort: the polling loop and its taskkill fallback decide that, unchanged.

The Store publication lag the reporter also hit (Store still serving 0.9.24) is not addressed here — that is a Store-side rollout question, and the installer's version resolution is unaffected by this change.

Testing

• New tests: the Store route rejects with the Start-menu message and never reaches msiexec or the network when the launch hook fails; the post-install route reports install itself succeeded when the launch after a real msi install fails.
• All 83 tests in tests/menubar-installer-windows.test.ts and 56 in tests/menubar-installer.test.ts pass; tsc --noEmit clean.
• Pre-publish review done by GLM-5.3-Flash (verdict: approve, no blocking issues); the three non-blocking suggestions from that review are folded in (empty-string doc on the hook, logged --quit spawn failure, clarifying suffixes on the msi routes).