fix(win): graceful shutdown, one startup-mode control, and a stray-\r bug

Windows-only changes, all found by actually running the previous session's
work rather than by review alone:

- CTRL_CLOSE_EVENT/LOGOFF/SHUTDOWN handler (platform.py, ctypes
  SetConsoleCtrlHandler) so closing a console window, signing off, or a
  system shutdown runs the daemon's real _shutdown() instead of Windows
  just ending the process — closing WebRTC sessions and any in-flight
  ffmpeg transcode instead of orphaning it. `taskkill /F` itself stays
  uncatchable (like SIGKILL), so autostart_run() now spawns with
  CREATE_NEW_PROCESS_GROUP instead of DETACHED_PROCESS and autostart_end()
  tries CTRL_BREAK_EVENT against the recorded pid first, falling back to
  the hard kill only if that doesn't stop it in time.

- Replaced the Node page's two independent autostart/service-mode toggles
  with one "start automatically" select (off / at sign-in / as a
  background service). The old pair let both be active at once — starting
  the daemon twice, at boot and at sign-in — and their layout broke
  wrapping inside .node-service's flex row. The new control always removes
  whichever mechanism is active before installing the target; platform.py's
  service_install() does the same on the CLI side. The "background
  service" option disables itself (with a hint pointing at the CLI) when
  running unpackaged, since service-mode.ps1/service.ps1/firewall.ps1 all
  assume an installed build's layout — verified live rather than assumed
  by actually running those scripts unelevated.

- findNodeBinary() no longer bakes a stray \r into resolved paths. Found by
  rebooting after enabling per-user autostart: where.exe listed two
  matches, and stdout.trim().split('\n')[0] only strips the whole string's
  ends, leaving line one's own trailing \r attached — which landed inside
  the Startup .vbs's quoted path and broke it with "Unterminated string
  constant" at boot. Fixed by splitting on \r?\n and trimming every line.

- Dependency audit for the Windows installer (docs/WINDOWS-PORT.md): no
  VC++ Redistributable needed, confirmed by inspecting the built
  node-runtime's actual import table rather than assuming. New
  docs/windows-build.md: a concise clone-to-installer build guide.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 92 insertions, 0 deletions

diff --git a/docs/windows-build.md b/docs/windows-build.md
new file mode 100644
index 0000000..88133cb
--- /dev/null
+++ b/docs/windows-build.md
@@ -0,0 +1,92 @@
+# Building MeshBay on Windows
+
+A quick, linear path from a fresh `git clone` to `MeshBay-Setup-<version>.exe`.
+For *why* things are done this way (firewall rules, autostart modes, the
+dependency surface, networking) see [`packaging/win/README.md`](../packaging/win/README.md)
+— this page is deliberately just the steps.
+
+## Prerequisites
+
+Install on the Windows machine that will build the installer:
+
+| Tool | Version | Check |
+|---|---|---|
+| [Node.js](https://nodejs.org) | 22 or newer | `node --version` |
+| Python | 3.12 or newer | `py -3.12 --version` (or `python --version`) |
+| Git | any recent | `git --version` |
+
+Nothing else — no VC++ Redistributable, no separate ffmpeg install. The build
+scripts create their own throwaway Python venv and fetch ffmpeg themselves.
+
+## 1. Clone
+
+```powershell
+git clone https://github.com/<owner>/meshbay.git
+cd meshbay
+```
+
+## 2. Build
+
+```powershell
+cd packages\meshbay-client
+npm run dist:win
+```
+
+This runs [`packaging/win/build-win.ps1`](../packaging/win/build-win.ps1), which:
+
+1. checks Node ≥ 22
+2. `npm ci` and downloads Electron's Chromium
+3. bumps Electron to its latest release (skip with `-NoElectronBump`)
+4. `npm run sync-ui` — copies the SPA from `meshbay-hub/.../static`
+5. runs [`build-node-runtime.ps1`](../packaging/win/build-node-runtime.ps1) —
+   creates a throwaway venv, installs `meshbay-node` + `meshbay-common`,
+   freezes the daemon with PyInstaller, fetches and verifies ffmpeg
+6. `electron-builder --win nsis`
+
+Expect this to take several minutes the first time (Chromium download,
+PyInstaller freeze, ffmpeg fetch). Output:
+
+```
+packages\meshbay-client\dist\MeshBay-Setup-<version>.exe
+```
+
+## 3. Options
+
+```powershell
+# smaller, streaming-less build for local iteration (skips the ~161 MB ffmpeg fetch)
+npm run dist:win -- -SkipFfmpeg
+
+# reuse an already-built node-runtime\ (faster iteration on the Electron side)
+powershell -File ..\..\packaging\win\build-win.ps1 -SkipNodeRuntime
+
+# keep Electron pinned instead of bumping to the latest release
+npm run dist:win -- -NoElectronBump
+```
+
+To rebuild just the frozen daemon on its own:
+
+```powershell
+powershell -File ..\..\packaging\win\build-node-runtime.ps1
+```
+
+## 4. Install and run
+
+Run `MeshBay-Setup-<version>.exe`. It is a **per-user** installer — no admin
+prompt unless you opt into service mode (background daemon that starts at
+boot, before sign-in) or accept the firewall rules, both offered during setup
+and both switchable afterwards from the Node page. Installs to
+`%LOCALAPPDATA%\Programs\MeshBay\`; runtime data lives in
+`%LOCALAPPDATA%\meshbay\`.
+
+## What's not automated yet
+
+- The installer is **unsigned** — Windows SmartScreen will warn on first run
+  (Authenticode signing is planned, not done).
+- No Windows CI runner builds this — it's a manual build today.
+- No genuine clean-machine (bare Windows 11 VM) install has been verified —
+  see `docs/WINDOWS-PORT.md` §5.4 for what has been checked instead.
+
+For everything else — what the installer actually contains, the two autostart
+modes, the firewall rules and why they're scoped the way they are, networking
+across NATs/VMs, and the dependency surface to watch when adding a Python
+package — read [`packaging/win/README.md`](../packaging/win/README.md).