fix: set the Windows node up at sign-in, and stop it for real

Found by the first Windows beta tester, then reproduced on a clean install.

After a service-mode install nothing set the node up for the account that
signed in: the boot task started a node that quit ("hub.username not set"),
and the sidebar showed Node / Create group only once the hub held a node key.
The only way to the wizard that provisions was the home page's welcome card,
which an account already in a group never sees. The way out was
`meshbay-node init` and the key pasted on the profile page -- which is also
what PACKAGING-GUIDE.md told people to do.

- main.js `node:ensure`, called by app.js at sign-in: provisions, starts and
  links the node this build ships (Windows, bundled node only). A node set up
  for another account, or an account linked to another node, is left alone.
  node:start waits for it, so the two never race.
- The sidebar shows the Node section when a node exists on this machine.
- The Node page's status is the node's: its control API and the process
  list, not the service task's state (a node started from a terminal ran
  while the page said Stopped). Stop says Stopped only once no
  meshbay-node.exe is left, and stays offered for a process that answers
  nothing.
- CLI stop kills the pid that answered when a graceful stop does not finish,
  and fails with the reason when a node process is still there.
- The daemon ends its process 3s after _shutdown(): Python's exit waited for a
  busy indexer thread, with the control API already closed. Armed by main()
  only, never by a daemon run inside a test.
- node.toml is read as utf-8-sig (PowerShell 5.1 writes a BOM), and a config
  that cannot be read is logged instead of dying silently in service mode.
- "Pair this browser" queues the code for the next group of this node to
  open instead of saying "Paired successfully"; no banner before a group.
- test_e2e_windows_app.py (opt-in, MESHBAY_WIN_E2E=1) drives the installed
  app against a throwaway hub: fresh account to linked node, Stop, Start,
  Restart, checked against the real processes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 35 insertions, 25 deletions

diff --git a/docs/PACKAGING-GUIDE.md b/docs/PACKAGING-GUIDE.md
index 9649826..fdc0a57 100644
--- a/docs/PACKAGING-GUIDE.md
+++ b/docs/PACKAGING-GUIDE.md
@@ -71,20 +71,21 @@ Run the installer. It is **per-user** and lands in
 node daemon ships beside the app at `resources\node-runtime\meshbay-node.exe`;
 the client finds it automatically.
 
-It asks two things, both skippable:
+It asks one thing — **when the node runs**:
 
-- **"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.
+- **As a background service** (the default) — the node starts **at boot,
+  before you even sign in**.
+- **Automatically when I sign in to Windows** — a launcher in your Startup
+  folder, no service.
+- **Only while MeshBay is open** — the app starts the node and stops it when
+  you quit.
 
-Running setup again (an upgrade, a repair install) asks neither question if
-the firewall rules are already there.
+Every choice also adds the Windows Firewall rules the app and the node need
+(WebRTC, casting), so setup asks for **one administrator confirmation**: for the
+service and the rules together, or for the rules alone. Running setup again (an
+upgrade, a repair) keeps the choice it finds and asks nothing when the rules and
+the service are already in place. The choice can be changed later on the
+**Node** page (**Start automatically**).
 
 **ffmpeg** — required for video streaming, **bundled in the installer by
 default** (verified, checksummed, GPLv3-licensed; `LICENSE-ffmpeg.txt` ships
@@ -92,29 +93,38 @@ alongside it). Nothing to install separately.
 
 ### First run
 
-Open MeshBay and sign in. Use the **Node** page (or a terminal) to provision:
+Open MeshBay, choose the hub and sign in. **That is all**: the app sets the node
+up for the account you signed in with, starts it the way you chose at install,
+and links it to your account. **Node** and **Create group** appear in the
+sidebar; nothing has to be typed in a terminal and no key has to be copied.
 
-```
-meshbay-node init
-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)
-```
+Two cases where the app does not do it on its own, because it would undo
+something:
+
+- the node was already set up for **another account or another hub** — the
+  **Start** button on the Node page asks before switching it;
+- your account is already linked to a node on **another machine** — linking
+  this one would disconnect that one. The Node page shows this node's key;
+  **Profile → Link Node** moves the link here if that is what you want.
+
+The Node page's **Start / Stop / Restart** work in every mode, and its status
+is the node's own: **Running** when it answers, **Stopped** only once no
+`meshbay-node.exe` is left. If a node will not stop, the page says so and why.
 
-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.
+The node logs to `%LOCALAPPDATA%\meshbay\state\node.log` — in service mode
+that file is the only place it can tell you why it would not start.
 
 Runtime data — `node.toml`, `keystore.enc`, `unlock.key`, `data\` — lives in
-`%LOCALAPPDATA%\meshbay\` and **survives uninstall/reinstall**, in either mode
+`%LOCALAPPDATA%\meshbay\` and **survives uninstall/reinstall**, in every 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 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
+entry. It stops a running node, removes the sign-in launcher, and removes the
+firewall rules and the boot-time service task with one administrator
+confirmation (none if neither is there). None of this touches
 `%LOCALAPPDATA%\meshbay\` (the keystore).
 
 ### Build from source