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, 145 insertions, 44 deletions

diff --git a/packages/meshbay-client/build/installer.nsh b/packages/meshbay-client/build/installer.nsh
index d2307c8..70858c6 100644
--- a/packages/meshbay-client/build/installer.nsh
+++ b/packages/meshbay-client/build/installer.nsh
@@ -1,16 +1,28 @@
 ; electron-builder NSIS customisation (auto-included: build/installer.nsh).
 ;
-; Per-user install, no elevation (package.json build.nsis). This does three
-; things beyond the default: put the bundled daemon on the user's PATH so
-; `meshbay-node` works in a terminal; offer to add the inbound firewall rules
-; in one elevated step instead of two "Allow access" dialogs later; and clean
-; up the one piece of state that lives outside the install directory (the W3
-; "run at sign-in" launcher).
+; Per-user install, no elevation (package.json build.nsis) -- that part never
+; changes. What this adds, all conditional on interactive setup (never
+; ${Silent}):
+;   - the bundled daemon dir on the user's PATH, so `meshbay-node` works in a
+;     terminal;
+;   - a choice of autostart: the normal per-user Startup-folder launcher (no
+;     admin, starts at sign-in -- see meshbay_node.platform._startup_vbs),
+;     or a background-service mode (one admin confirmation, starts at boot,
+;     no sign-in required -- see meshbay_node.platform.service_install and
+;     packaging/win/service.ps1);
+;   - the inbound firewall rules, folded into that SAME elevation when service
+;     mode is chosen, or offered on their own otherwise -- never two UAC
+;     prompts for one install;
+;   - cleanup of whichever of those is outside $INSTDIR on the way out (the
+;     Startup .vbs; the scheduled task and firewall rules, together, if the
+;     user opts in).
 ;
 ; Deliberately NOT touched:
 ;   - %LOCALAPPDATA%\meshbay\  (node.toml, keystore.enc, unlock.key, data/) --
 ;     the keystore must survive an uninstall/reinstall; installers place files,
-;     never remove secrets.
+;     never remove secrets. This is also why service mode needs no code
+;     changes to platform.py: it runs as this same user (S4U), so it is the
+;     same profile either way.
 
 !include "WinMessages.nsh"
 !include "WordFunc.nsh"
@@ -40,27 +52,42 @@
   WriteRegExpandStr HKCU "Environment" "Path" "$1"
   SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000
 
-  ; Firewall. MeshBay.exe / meshbay-node.exe (WebRTC) and MeshBay.exe again
-  ; (LAN cast) each need an inbound allow, and Windows prompts "Allow access"
-  ; the first time each does. A per-user installer cannot pre-create a
-  ; firewall rule (that needs admin), so offer one elevated helper: one UAC
-  ; prompt instead of up to four dialogs spread across first use.
-  ;
-  ; Checked first, UNELEVATED (Get-NetFirewallRule needs no admin, only
-  ; New/Remove do) -- so re-running setup with the rules already in place
-  ; asks nothing and never pops UAC again.
-  nsExec::Exec '"${MB_PWSH}" -NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" check'
-  Pop $0
-  ${If} $0 != 0
-    ${IfNot} ${Silent}
+  ${IfNot} ${Silent}
+    ; Already configured -- an upgrade, or a repair install -- asks nothing.
+    ; Checked unelevated: reading firewall rules needs no admin, only
+    ; creating them does (same reasoning as the service task below). Whether
+    ; service mode or per-user mode was chosen last time, firewall rules
+    ; existing already means there is nothing left for this dialog to do.
+    nsExec::Exec '"${MB_PWSH}" -NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" check'
+    Pop $0
+    ${If} $0 == 0
+      Goto mb_mode_done
+    ${EndIf}
+
+    ; The choice. Service mode needs admin to CREATE (a boot trigger touches
+    ; system-wide scheduler state -- the same reason /sc onlogon needed it
+    ; too); day-to-day start/stop from the Node page does not, once the task
+    ; exists, because Task Scheduler grants the owning user that much itself.
+    MessageBox MB_YESNO|MB_ICONQUESTION \
+      "Run MeshBay Node as a background service?$\n$\nIt starts automatically at boot, even before you sign in, and needs one administrator confirmation now (which also sets up the Windows Firewall rules, in the same step).$\n$\nChoose No for the normal per-user mode instead: it starts when you sign in, no admin needed, and you will be asked about the firewall rules separately." \
+      IDNO mb_peruser_mode
+
+      ; -- Service mode: one elevation, both jobs --------------------------
+      ExecShellWait "runas" "${MB_PWSH}" \
+        '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\service-mode.ps1" -Action install' \
+        SW_HIDE
+      Goto mb_mode_done
+
+    mb_peruser_mode:
+      ; -- Per-user mode: the firewall question stands on its own ----------
       MessageBox MB_YESNO|MB_ICONQUESTION \
         "Allow MeshBay through Windows Firewall now?$\n$\nMeshBay connects to other devices on your local network. Choosing Yes adds the rules in one step (Windows will ask for administrator confirmation). Choosing No is fine too -- Windows will ask you to allow access the first time MeshBay connects." \
-        /SD IDYES IDNO mb_skip_fw
+        /SD IDYES IDNO mb_mode_done
         ExecShellWait "runas" "${MB_PWSH}" \
           '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" add' \
           SW_HIDE
-      mb_skip_fw:
-    ${EndIf}
+
+    mb_mode_done:
   ${EndIf}
 !macroend
 
@@ -73,18 +100,21 @@
   WriteRegExpandStr HKCU "Environment" "Path" "$1"
   SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000
 
-  ; Offer to take the firewall rules back out (needs admin again). A stale
-  ; allow-rule pointing at a deleted exe is inert, so this is opt-in and
-  ; default-No -- a silent uninstall skips it entirely. customUnInstall runs
-  ; before the files are removed, so firewall.ps1 is still there.
+  ; Offer to take the firewall rules, and the service task if one was set up,
+  ; back out together (needs admin again -- one prompt for both, same as
+  ; install). Both underlying removes are no-ops when there is nothing to
+  ; remove, so this is safe to run unconditionally regardless of which mode
+  ; was chosen. Stale rules/tasks are inert if left, so this is opt-in and
+  ; default-No; a silent uninstall skips it entirely. customUnInstall runs
+  ; before the files are removed, so service-mode.ps1 is still there.
   ${IfNot} ${Silent}
     MessageBox MB_YESNO|MB_ICONQUESTION \
-      "Remove MeshBay's Windows Firewall rules? This needs one administrator confirmation. They are harmless if left." \
-      /SD IDNO IDNO mb_keep_fw
+      "Remove MeshBay's Windows Firewall rules and its boot-time service task, if you set one up? This needs one administrator confirmation. Both are harmless if left." \
+      /SD IDNO IDNO mb_keep_privileged
       ExecShellWait "runas" "${MB_PWSH}" \
-        '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" remove' \
+        '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\service-mode.ps1" -Action remove' \
         SW_HIDE
-    mb_keep_fw:
+    mb_keep_privileged:
   ${EndIf}
 
   ; meshbay_node.platform._startup_vbs() -- if the user ran "meshbay-node
diff --git a/packages/meshbay-client/package.json b/packages/meshbay-client/package.json
index 7f5afcb..55b2dcf 100644
--- a/packages/meshbay-client/package.json
+++ b/packages/meshbay-client/package.json
@@ -1,6 +1,6 @@
 {
   "name": "meshbay-client",
-  "version": "0.1.0",
+  "version": "1.0.0",
   "description": "MeshBay desktop client — the interface ships with the application, not from the hub",
   "license": "AGPL-3.0-or-later",
   "author": "MeshBay Team <team@meshbay.org>",
@@ -37,6 +37,14 @@
         {
           "from": "../../packaging/win/firewall.ps1",
           "to": "firewall.ps1"
+        },
+        {
+          "from": "../../packaging/win/service.ps1",
+          "to": "service.ps1"
+        },
+        {
+          "from": "../../packaging/win/service-mode.ps1",
+          "to": "service-mode.ps1"
         }
       ]
     },
diff --git a/packages/meshbay-client/src/main.js b/packages/meshbay-client/src/main.js
index b0505a9..15c3cc0 100644
--- a/packages/meshbay-client/src/main.js
+++ b/packages/meshbay-client/src/main.js
@@ -850,6 +850,38 @@ function registerBridge() {
     });
   }
 
+  // ── Windows: the opt-in Scheduled Task "service mode" ──────────────────────
+  // Set up once, elevated, at install time (build/installer.nsh + packaging/win
+  // /service.ps1 + /service-mode.ps1) or via `meshbay-node service install`
+  // from an elevated prompt — this process never creates or deletes it, only
+  // queries and drives an existing one, which needs no elevation (Task
+  // Scheduler grants the owning user that much itself). Kept in step with
+  // meshbay_node.platform.TASK_NAME / service_status().
+  const WIN_SERVICE_TASK = 'MeshBay Node';
+
+  function winServiceTaskStatus() {
+    return new Promise((resolve) => {
+      execFile('schtasks', ['/query', '/tn', WIN_SERVICE_TASK, '/fo', 'list'],
+        (err, stdout) => {
+          if (err) return resolve({ installed: false, state: '' });
+          const m = (stdout || '').split(/\r?\n/).find((l) => /^status:/i.test(l.trim()));
+          resolve({ installed: true, state: m ? m.split(':')[1].trim() : '' });
+        });
+    });
+  }
+
+  function winServiceTaskRun() {
+    return new Promise((resolve) => {
+      execFile('schtasks', ['/run', '/tn', WIN_SERVICE_TASK], () => resolve());
+    });
+  }
+
+  function winServiceTaskEnd() {
+    return new Promise((resolve) => {
+      execFile('schtasks', ['/end', '/tn', WIN_SERVICE_TASK], () => resolve());
+    });
+  }
+
   async function spawnNodeDetached() {
     const bin = await findNodeBinary();
     if (!bin) throw new Error('meshbay-node not found on PATH');
@@ -875,8 +907,12 @@ function registerBridge() {
 
   ipcMain.handle('node:installed', async () => {
     if (process.platform === 'win32') {
-      const bin = await findNodeBinary();
-      return { installed: Boolean(bin), autostart: winAutostartInstalled() };
+      const [bin, svc] = await Promise.all([findNodeBinary(), winServiceTaskStatus()]);
+      return {
+        installed: Boolean(bin),
+        autostart: winAutostartInstalled(),
+        service: svc.installed,
+      };
     }
     if (process.platform !== 'linux') return { installed: false };
     const unit = await new Promise((resolve) => {
@@ -897,16 +933,29 @@ function registerBridge() {
   // looping — exactly the states this panel exists to show and act on.
   ipcMain.handle('node:service-status', async () => {
     if (process.platform === 'win32') {
-      // No Task Scheduler to ask "is it running" — probe the daemon itself.
-      // `installed` used to be winAutostartInstalled(), which is wrong: it
-      // answers "does the Startup launcher exist", not "is there a daemon to
-      // manage". The Node page's Stop/Restart buttons are gated on
-      // `installed`, so with no autostart configured they silently vanished
-      // — the daemon was perfectly manageable, just not launchable at
-      // sign-in. `autostart` carries that state as its own field instead.
+      const svc = await winServiceTaskStatus();
+      if (svc.installed) {
+        // Service mode: Task Scheduler already tracks running/not, directly —
+        // no need to probe the daemon's own API for this panel.
+        const running = /running/i.test(svc.state);
+        return {
+          supported: true,
+          mode: 'service',
+          installed: true,
+          activeState: running ? 'active' : 'inactive',
+          subState: svc.state,
+        };
+      }
+      // Per-user Startup mode. `installed` used to be winAutostartInstalled(),
+      // which is wrong: it answers "does the Startup launcher exist", not "is
+      // there a daemon to manage". The Node page's Stop/Restart buttons are
+      // gated on `installed`, so with no autostart configured they silently
+      // vanished — the daemon was perfectly manageable, just not launchable
+      // at sign-in. `autostart` carries that state as its own field instead.
       const [p, bin] = await Promise.all([probeNode(), findNodeBinary()]);
       return {
         supported: true,
+        mode: 'startup',
         installed: Boolean(bin),
         autostart: winAutostartInstalled(),
         activeState: p ? 'active' : 'inactive',
@@ -939,7 +988,10 @@ function registerBridge() {
 
   ipcMain.handle('node:service-stop', async () => {
     if (process.platform === 'win32') {
-      await killNodeProcesses();   // hard kill — no CTRL_CLOSE handler yet
+      const svc = await winServiceTaskStatus();
+      if (svc.installed) await winServiceTaskEnd();
+      await killNodeProcesses();   // hard kill — no CTRL_CLOSE handler yet;
+      // also the belt-and-suspenders in case /end left the process running
       return { stopped: true };
     }
     if (process.platform !== 'linux') {
@@ -957,8 +1009,14 @@ function registerBridge() {
 
   ipcMain.handle('node:service-restart', async () => {
     if (process.platform === 'win32') {
+      const svc = await winServiceTaskStatus();
+      if (svc.installed) await winServiceTaskEnd();
       await killNodeProcesses();
-      await spawnNodeDetached();
+      if (svc.installed) {
+        await winServiceTaskRun();
+      } else {
+        await spawnNodeDetached();
+      }
       const p = await waitForNode(Date.now() + 30000);
       if (!p) throw new Error('node did not come back up within 30s');
       return { restarted: true, ...p };
@@ -1064,7 +1122,12 @@ function registerBridge() {
     if (process.platform === 'win32') {
       if (opts && opts.hubUrl && opts.username) provisionNode(opts.hubUrl, opts.username);
       await killNodeProcesses();   // clear a crash-looping one
-      await spawnNodeDetached();
+      const svc = await winServiceTaskStatus();
+      if (svc.installed) {
+        await winServiceTaskRun();
+      } else {
+        await spawnNodeDetached();
+      }
       const p = await waitForNode(Date.now() + 60000);
       if (!p) throw new Error('the node did not start within 60s — run it from a '
         + 'terminal (`meshbay-node`) to see why');