feat: opt-in Windows service mode (boot-time, one elevation) + v1.0.0

The per-user Startup-folder launcher (W3) only ever runs after this user
signs in. A real Windows Service would start earlier, but under
LocalSystem/NetworkService -- accounts with no normal profile, so
%LOCALAPPDATA%\meshbay\ (config, keystore, data) would not exist for it.
Relocating storage to make that work is real surgery, deliberately not
done here.

Instead: a Scheduled Task, created once with admin rights, that runs AS
THIS USER at boot without needing them to sign in first.
`schtasks /create ... /ru <user> /rp ""` with no `/it` registers an S4U
(Service For User) logon -- no password stored anywhere, and unlike
LocalSystem it loads this account's own profile, so config_dir()/
data_dir() need zero changes. The cost: S4U carries no network credential,
which the node never needed -- everything it touches is local disk plus
outbound internet. Creating the task needs admin (a boot trigger touches
system-wide scheduler state, the same reason /sc onlogon needed it);
querying/starting/stopping an existing one does not -- Task Scheduler
grants the owning user that much itself, which is what lets the Node
page's Start/Stop/Restart drive it with no further UAC prompts.

meshbay_node/platform.py
  service_install/_remove/_status/_run/_end -- mirrors autostart_* but
  for the Scheduled Task; TASK_NAME moved here (was decorative before)

meshbay_node/daemon.py
  new `service install|remove|start|stop|status` verb; restart-daemon and
  reset now check for the service task too

packaging/win/service.ps1
  the installer-side equivalent (extraResource); status/run/end never
  self-elevate -- only install/remove do, exactly matching what
  Task Scheduler itself requires

packaging/win/service-mode.ps1
  ONE elevated helper running service.ps1 + firewall.ps1 together, so
  choosing service mode costs exactly one UAC prompt, not two

build/installer.nsh
  the install-time choice: "run as a background service?" (one
  elevation, both jobs) vs the existing per-user + separate firewall
  question. Checked first, unelevated, so re-running setup with
  everything already configured asks nothing. Uninstall offers the
  matching one-elevation cleanup, default No.

src/main.js
  winServiceTaskStatus/Run/End, wired into node:installed,
  node:service-status/-stop/-restart and node:start: when the Scheduled
  Task exists, drive it; otherwise fall back to the existing per-user
  spawn/kill path. This is the hard requirement -- Start/Stop/Restart
  from the Node page must work in either mode.

node-page.js / locales
  a hint explaining why the per-user autostart toggle is absent when
  service mode is active (info.mode from the backend, no new field to
  gate on -- it just isn't sent in that case)

package.json: 0.1.0 -> 1.0.0.

Verified: electron-builder compiles the new NSIS choice logic and ships
all three scripts; service.ps1's S4U install fails cleanly (Access
denied) when run unelevated, and its status/run/end never touch "runas".
Cannot verify the elevated success path myself (no admin in this
session) -- that needs a real UAC click. Node suite 843 pass / 25 skip;
test_packaging_win.py pins the one-elevation property, the S4U flags,
and that main.js actually checks the service task in all three handlers.

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

1 files changed, 28 insertions, 10 deletions

diff --git a/docs/PACKAGING-GUIDE.md b/docs/PACKAGING-GUIDE.md
index c4f6b00..4dcda30 100644
--- a/docs/PACKAGING-GUIDE.md
+++ b/docs/PACKAGING-GUIDE.md
@@ -67,15 +67,24 @@ node (with `meshbay-common` inside it). There is no Windows hub.
 ### Install
 
 Run the installer. It is **per-user** and lands in
-`%LOCALAPPDATA%\Programs\meshbay-client\` without needing admin rights. The
+`%LOCALAPPDATA%\Programs\MeshBay\` without needing admin rights. The
 node daemon ships beside the app at `resources\node-runtime\meshbay-node.exe`;
 the client finds it automatically.
 
-It does ask one thing: **"Allow MeshBay through Windows Firewall now?"** —
-say yes and one administrator confirmation adds both inbound rules the client
-and the node need for WebRTC. Say no and the install finishes the same either
-way; Windows will show its own "Allow access" dialog instead, once for each,
-the first time they actually need to accept a connection.
+It asks two things, both skippable:
+
+- **"Run MeshBay Node as a background service?"** — Yes starts the node **at
+  boot, before you even sign in**, and needs one administrator confirmation
+  (which also sets up the firewall rules, in the same step — see below). No
+  keeps the normal per-user mode: the node starts when you sign in, with no
+  admin needed, and you can turn autostart on later from the Node page.
+- **(per-user mode only) "Allow MeshBay through Windows Firewall now?"** — one
+  administrator confirmation adds the inbound rules the client and the node
+  need for WebRTC and casting. Declining is fine — Windows shows its own
+  "Allow access" dialog instead, the first time each is actually used.
+
+Running setup again (an upgrade, a repair install) asks neither question if
+the firewall rules are already there.
 
 **ffmpeg** is required for video streaming and is *not* in the installer unless
 it was built with `-FfmpegDir`. Otherwise install it separately
@@ -87,17 +96,26 @@ Open MeshBay and sign in. Use the **Node** page (or a terminal) to provision:
 
 ```
 meshbay-node init
-meshbay-node autostart install     # run the daemon at every sign-in (no admin)
+meshbay-node autostart install     # per-user mode: run at every sign-in (no admin)
+meshbay-node service install       # service mode: run at boot (needs an elevated prompt)
 ```
 
+The Node page's Start/Stop/Restart buttons work the same either way — they
+drive the Scheduled Task when service mode is active, or the daemon process
+directly otherwise.
+
 Runtime data — `node.toml`, `keystore.enc`, `unlock.key`, `data\` — lives in
-`%LOCALAPPDATA%\meshbay\` and **survives uninstall/reinstall**.
+`%LOCALAPPDATA%\meshbay\` and **survives uninstall/reinstall**, in either mode
+(service mode runs as your own account too — never LocalSystem — so nothing
+about where your data lives changes).
 
 ### Uninstall
 
 *Apps & features → MeshBay → Uninstall*, or the Start-menu *Uninstall MeshBay*
-entry. It stops a running daemon and removes the sign-in launcher; it does not
-touch `%LOCALAPPDATA%\meshbay\` (the keystore).
+entry. It stops a running daemon and removes the sign-in launcher; it offers
+(opt-in, one admin confirmation) to also remove the firewall rules and the
+boot-time service task, if you set one up. None of this touches
+`%LOCALAPPDATA%\meshbay\` (the keystore).
 
 ### Build from source