fix(win): a service-mode daemon can be replaced, and the Node page can link one

Two live-reproduced bugs in Windows node start/stop, found sideloading the
0.14.0 build:

- node:start's crash-recovery step killed a service-mode daemon with
  taskkill/CTRL_BREAK, both of which fail with "Access is denied" against a
  process running under the Scheduled Task's own S4U logon session (a
  different session from the Electron app's). The daemon it was meant to
  replace just kept running, unreplaced, and schtasks /run on a task Windows
  still considered Running was then a silent no-op too. Route through
  winServiceTaskEnd() (schtasks /end) first, the way nodeServiceStop/
  nodeServiceRestart already correctly do. service-mode.ps1 also now starts
  the task right after registering it -- Register-ScheduledTask's own
  AtStartup trigger does not run it immediately, so nothing was listening
  until the next reboot.

- The Node page's Start button called node.start() with no arguments, so an
  unlinked node (a fresh install, or one whose hub-side link was lost) could
  never link on Start alone -- only create-group-page.js's own call passed
  {hubUrl, username, token}. Reproduced on a fresh non-service install signed
  in to the real hub: Start hung for ~105s and failed with "could not link",
  pointing at a "Link Node" control that lives on Settings, not the Node
  page (that message is fixed too).

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

1 files changed, 19 insertions, 3 deletions

diff --git a/packages/meshbay-client/src/main.js b/packages/meshbay-client/src/main.js
index bebe144..f201a21 100644
--- a/packages/meshbay-client/src/main.js
+++ b/packages/meshbay-client/src/main.js
@@ -1567,11 +1567,24 @@ function registerBridge() {
 
     if (process.platform === 'win32') {
       if (opts && opts.hubUrl && opts.username) provisionNode(opts.hubUrl, opts.username);
-      await killNodeProcesses();   // clear a crash-looping one
       const svc = await winServiceTaskStatus();
       if (svc.installed) {
+        // A service-mode daemon runs under the task's own S4U logon session,
+        // not this (interactive) one -- killNodeProcesses()'s taskkill and
+        // CTRL_BREAK both target it by image name/pid from here, and both
+        // fail with "Access is denied" across that session boundary
+        // (confirmed live 2026-09-14: an already-elevated `schtasks /end`
+        // succeeds against the exact same pid taskkill just refused).
+        // Silently, too -- killNodeProcesses() never surfaces the failure,
+        // so a stuck instance was never actually replaced: re-running the
+        // task below is then a no-op too, since Windows still considers it
+        // Running (default "do not start a new instance" policy). Task Scheduler can
+        // stop what it started; go through it, the way nodeServiceStop/
+        // nodeServiceRestart already correctly do, instead of reaching past it.
+        await winServiceTaskEnd();
         await winServiceTaskRun();
       } else {
+        await killNodeProcesses();   // clear a crash-looping one (same session)
         await spawnNodeDetached();
       }
       const p = await waitForNode(Date.now() + 60000);
@@ -1585,9 +1598,12 @@ function registerBridge() {
         ? p
         : await linkNodeKeyAndAwaitRunning(opts, Date.now() + 45000);
       if (!ready || ready.status !== 'running') {
+        // "Link Node" is on the Settings page, not this one -- pointing here
+        // at the Node page sent whoever read this hunting for a control that
+        // is not on it (reproduced live 2026-09-14).
         throw new Error(
-          'the node started but could not link to your hub account. Open the '
-          + 'Node page and use "Link this node", or check you are signed in to '
+          'the node started but could not link to your hub account. Open '
+          + 'Settings and use "Link Node", or check you are signed in to '
           + 'the hub this node is configured for.');
       }
       return { started: true, ...ready };