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>

3 files changed, 185 insertions, 2 deletions

diff --git a/packaging/win/README.md b/packaging/win/README.md
index 01c8d1a..7bbec13 100644
--- a/packaging/win/README.md
+++ b/packaging/win/README.md
@@ -7,11 +7,13 @@ Linux). `meshbay-common` rides along inside the node runtime.
 ## What the installer contains
 
 ```
-%LOCALAPPDATA%\Programs\meshbay-client\
+%LOCALAPPDATA%\Programs\MeshBay\          (productName, not the npm package name)
 ├─ MeshBay.exe                     Electron client
 ├─ resources\
 │  ├─ app.asar                     src/ + ui/ (the interface ships in the package)
-│  ├─ firewall.ps1                 adds/removes the two inbound rules (see below)
+│  ├─ firewall.ps1                 adds/removes the four inbound rules (see below)
+│  ├─ service.ps1                  install/remove/status/run/end the boot-time task
+│  ├─ service-mode.ps1             elevated helper: service.ps1 + firewall.ps1 in one UAC prompt
 │  └─ node-runtime\
 │     ├─ meshbay-node.exe          frozen daemon (PyInstaller onedir)
 │     ├─ _internal\ …              its Python + deps (aiortc, av, aioquic, …)
@@ -22,6 +24,9 @@ Linux). `meshbay-common` rides along inside the node runtime.
 Runtime data stays where the node already puts it: `%LOCALAPPDATA%\meshbay\`
 (`node.toml`, `keystore.enc`, `unlock.key`, `data\`). The installer never writes
 there and the uninstaller never deletes it — installers place files, not secrets.
+That is also why service mode needed no code changes to `platform.py`: it runs
+as this same signed-in user (S4U, see below), so it is the same profile either
+way — not LocalSystem/NetworkService, which would have none of this.
 
 `build/installer.nsh` also adds `…\resources\node-runtime` to the **per-user**
 `Path` (`HKCU\Environment`) so `meshbay-node` works in a terminal, and takes it
@@ -29,6 +34,42 @@ back out on uninstall. New shells only — a `WM_SETTINGCHANGE` broadcast nudges
 open ones. It uses stock `WordFunc.nsh` (the `EnVar` plugin is not in
 electron-builder's NSIS bundle).
 
+## Autostart: two modes, one choice at install time
+
+**Per-user (default, no admin).** A `.vbs` in the Startup folder
+(`meshbay_node.platform._startup_vbs`), toggled from the Node page or
+`meshbay-node autostart install|remove`. Starts when *this user* signs in.
+
+**Service mode (one admin confirmation, at install time only).** A Scheduled
+Task, `meshbay_node.platform.service_install` / `packaging/win/service.ps1`,
+that starts **at boot, before anyone signs in**. A real Windows Service would
+run under LocalSystem/NetworkService — accounts with no normal user profile,
+so `%LOCALAPPDATA%\meshbay\` (config, keystore, data) would not exist for it.
+Relocating storage to make that work is real surgery, deliberately not this.
+
+The alternative used instead: `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
+`%LOCALAPPDATA%\meshbay\` keeps working with zero code changes. The cost: S4U
+carries no network credential (cannot reach a domain share as this user),
+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 too, back when Task Scheduler
+was tried for the per-user mode and abandoned for exactly that reason).
+Querying, starting and stopping an *already-created* task 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
+(`src/main.js`'s `winServiceTaskStatus/Run/End`, mirroring `service.ps1`).
+
+**One elevation, not two.** Choosing service mode needs admin for both the
+Scheduled Task *and* the firewall rules; `service-mode.ps1` runs both from a
+single `ExecShellWait "runas"` in `installer.nsh`, so the choice costs exactly
+one UAC prompt. Re-running setup (an upgrade, a repair install) asks nothing
+if the firewall rules are already there — checked first, unelevated, the same
+pattern the per-user-only firewall step already used.
+
 ## Build
 
 On a Windows machine with **Node ≥ 22**, **Python ≥ 3.12** (`py -3.12`) and
diff --git a/packaging/win/service-mode.ps1 b/packaging/win/service-mode.ps1
new file mode 100644
index 0000000..e522f04
--- /dev/null
+++ b/packaging/win/service-mode.ps1
@@ -0,0 +1,55 @@
+<#
+.SYNOPSIS
+    Elevated helper: set up (or tear down) service mode in ONE UAC prompt,
+    not two.
+
+.DESCRIPTION
+    "Run as a background service" is two things -- the boot-time Scheduled
+    Task and the firewall rules -- and needs one elevation, not one each.
+    build/installer.nsh runs this single script via ExecShellWait "runas"
+    for both the install-time choice and the uninstaller's cleanup, instead
+    of elevating service.ps1 and firewall.ps1 separately.
+
+    Each stays a script of its own rather than being folded together, so both
+    remain independently callable and testable -- the CLI does, through
+    meshbay-node service, and so does a later "just fix the firewall rules"
+    retry that has nothing to do with the service task.
+
+    Logs to the same file firewall.ps1 already uses, so both are visible in
+    one place: %TEMP%\meshbay-firewall.log.
+
+.PARAMETER Action
+    install  service.ps1 install, then firewall.ps1 add
+    remove   service.ps1 remove,  then firewall.ps1 remove
+#>
+[CmdletBinding()]
+param(
+    [ValidateSet("install", "remove")]
+    [string]$Action = "install"
+)
+
+$here = $PSScriptRoot
+$log = Join-Path $env:TEMP "meshbay-firewall.log"
+$firewallAction = if ($Action -eq "install") { "add" } else { "remove" }
+$failed = $false
+
+"[{0}] service-mode {1}" -f (Get-Date -Format s), $Action | Add-Content $log
+
+try {
+    & (Join-Path $here "service.ps1") $Action
+}
+catch {
+    "  service $Action failed: $_" | Add-Content $log
+    $failed = $true
+}
+
+try {
+    & (Join-Path $here "firewall.ps1") $firewallAction
+}
+catch {
+    "  firewall $firewallAction failed: $_" | Add-Content $log
+    $failed = $true
+}
+
+if ($failed) { exit 1 }
+exit 0
diff --git a/packaging/win/service.ps1 b/packaging/win/service.ps1
new file mode 100644
index 0000000..936c060
--- /dev/null
+++ b/packaging/win/service.ps1
@@ -0,0 +1,87 @@
+<#
+.SYNOPSIS
+    Install/remove/query/run/end the "MeshBay Node" boot-time Scheduled Task.
+
+.DESCRIPTION
+    A real Windows Service runs under LocalSystem/NetworkService before anyone
+    signs in -- but those accounts have no normal user profile, and this app's
+    entire design keeps node.toml, the keystore and all data under the signed-in
+    user's own %LOCALAPPDATA%\meshbay\. Running as LocalSystem would not find
+    any of it.
+
+    The middle ground, and what this script sets up: a Scheduled Task that runs
+    AS THIS USER at system 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 %LOCALAPPDATA%\meshbay\
+    keeps working with zero changes. The cost: S4U carries no network
+    credential (no reaching a domain share as this user), which the node never
+    needed -- everything it touches is local disk plus outbound internet.
+
+    Mirrors meshbay_node.platform.service_install/_remove/_status/_run/_end --
+    same TASK_NAME, same flags -- so the CLI and the installer agree on what
+    "installed" means. install/remove need admin (a boot trigger touches
+    system-wide scheduler state); status/run/end do not, once the task exists,
+    because Task Scheduler grants the owning user that much by default -- which
+    is what lets the Node page's Start/Stop/Restart drive it with no further
+    UAC prompts.
+
+    Shipped as an extraResource at <install>\resources\service.ps1, so it
+    locates meshbay-node.exe from its own path.
+
+.PARAMETER Action
+    install | remove | status | run | end
+#>
+[CmdletBinding()]
+param(
+    [ValidateSet("install", "remove", "status", "run", "end")]
+    [string]$Action = "status"
+)
+
+# Not "Stop": schtasks writes its normal "task not found" outcome to stderr,
+# and with ErrorActionPreference=Stop that promotes to a terminating error
+# even through a 2>$null redirect (a native command's stderr is converted to
+# an ErrorRecord before the redirect discards it). Every exit path below
+# checks $LASTEXITCODE explicitly instead.
+$TASK_NAME = "MeshBay Node"
+$resources = $PSScriptRoot
+$node      = Join-Path $resources "node-runtime\meshbay-node.exe"
+
+function Get-CurrentUser {
+    $domain = $env:USERDOMAIN
+    if (-not $domain) { $domain = $env:COMPUTERNAME }
+    return "$domain\$env:USERNAME"
+}
+
+switch ($Action) {
+    "install" {
+        if (-not (Test-Path $node)) { throw "meshbay-node.exe not found at $node" }
+        $user = Get-CurrentUser
+        & schtasks /create /tn $TASK_NAME /tr "`"$node`"" /sc onstart /ru $user /rp "" /rl limited /f
+        if ($LASTEXITCODE -ne 0) { throw "schtasks /create failed (exit $LASTEXITCODE)" }
+        Write-Host "service: installed ($user, runs at boot)"
+    }
+    "remove" {
+        & schtasks /delete /tn $TASK_NAME /f 2>$null | Out-Null
+        Write-Host "service: removed"
+    }
+    "status" {
+        $out = & schtasks /query /tn $TASK_NAME /fo list 2>$null
+        if ($LASTEXITCODE -ne 0) {
+            Write-Output "NOT_INSTALLED"
+            exit 1
+        }
+        $line = $out | Select-String "^Status:"
+        $state = if ($line) { ($line -replace "^Status:\s*", "").Trim() } else { "unknown" }
+        Write-Output "INSTALLED:$state"
+        exit 0
+    }
+    "run" {
+        & schtasks /run /tn $TASK_NAME
+        if ($LASTEXITCODE -ne 0) { throw "schtasks /run failed (exit $LASTEXITCODE)" }
+    }
+    "end" {
+        & schtasks /end /tn $TASK_NAME
+        if ($LASTEXITCODE -ne 0) { throw "schtasks /end failed (exit $LASTEXITCODE)" }
+    }
+}