feat: Windows daemon lifecycle (W3) — Startup-folder autostart

The Linux node runs under `systemctl --user`. Windows has no per-user
equivalent that works without elevation: `schtasks /create /sc ONLOGON`
(even `/rl LIMITED /it`) fails with "Access is denied" for a non-admin
user, because a logon trigger touches machine-wide scheduler state.

So autostart is a `.vbs` in the per-user Startup folder instead:

    CreateObject("WScript.Shell").Run Chr(34) & "<exe>" & Chr(34), 0, False

wscript runs it at every sign-in, hidden (0) and non-blocking. No admin,
no console window, no new dependency. Verified end to end: the launcher
brings the daemon up with no window and it answers its loopback API.

node/platform.py
  autostart_install/remove/status  — write / delete / detect the launcher
  autostart_run/end                — start now (DETACHED|NO_WINDOW) / taskkill
  _node_exe                        — PATH, then next to sys.executable, then argv[0]

node/daemon.py
  new `autostart install|remove|start|stop|status` verb
  reload (win32)         -> POST /api/reload on the loopback API
  restart-daemon (win32) -> autostart_end + autostart_run
  reset (win32)          -> also removes the launcher

client/main.js, preload.js
  node:autostart handler + winAutostart* helpers (kept in step with platform.py)
  node:service-status (win32) probes the daemon; stop/restart/start use
  taskkill + a detached, windowless spawn

Tests: 8 autostart cases in test_platform.py (mocked sys.platform, APPDATA
pointed at tmp); `autostart status` added to the CLI dispatch sweep. Full
meshbay-node suite green on Windows (784 passed / 34 skipped).

Still open: no CTRL_CLOSE_EVENT handler, so a bare taskkill / window close
does not run _shutdown() (SetConsoleCtrlHandler, follow-up). Service mode
(pywin32/NSSM) stays Phase 2.

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

1 files changed, 8 insertions, 2 deletions

diff --git a/packages/meshbay-client/src/preload.js b/packages/meshbay-client/src/preload.js
index 96d6790..38c1a57 100644
--- a/packages/meshbay-client/src/preload.js
+++ b/packages/meshbay-client/src/preload.js
@@ -97,13 +97,19 @@ contextBridge.exposeInMainWorld('meshbay', {
     call: (method, path, body) => ipcRenderer.invoke('node:call', method, path, body),
     pairingCode: () => ipcRenderer.invoke('node:pairing-code'),
     setPairingCode: (code) => ipcRenderer.invoke('node:set-pairing-code', code),
-    // The systemd unit's own state — reachable even while the daemon itself
-    // is stopped or crash-looping, which `call()` above is not.
+    // The daemon's lifecycle as seen from outside it: the systemd unit (Linux)
+    // or, on Windows, a probe of the daemon plus whether the Startup launcher
+    // is in place — reachable even while the daemon itself is stopped or
+    // crash-looping, which `call()` above is not.
     service: {
       status: () => ipcRenderer.invoke('node:service-status'),
       stop: () => ipcRenderer.invoke('node:service-stop'),
       restart: () => ipcRenderer.invoke('node:service-restart'),
     },
+    // Windows only: the "run at every sign-in" Startup-folder launcher.
+    // action: 'install' | 'remove' | 'status' (default). Elsewhere returns
+    // { supported: false }.
+    autostart: (action) => ipcRenderer.invoke('node:autostart', action),
   },
 
   // LAN cast relay. The main process runs a local HTTP server and the