test(node): pin the fresh-install-before-provisioning safety property

Two properties discussed but not yet pinned by a test, both load-bearing
for service mode:

1. A bare `meshbay-node` with no config yet -- exactly what the W3
   Startup .vbs and the service-mode Scheduled Task both run unattended,
   on the very first boot after a fresh install, quite possibly before
   the user has ever opened the client -- must fail closed, fast, and
   without a trace. Measured by hand first (under a second, zero bytes
   written against a real empty %LOCALAPPDATA%); this pins it as a test
   so it can't regress silently. load_config() already returns an empty
   Config on a missing path rather than raising, so main() reaches its
   own "hub.username not set" exit before ever touching NodeDaemon() or
   asyncio.run() -- nothing here has to mock the daemon startup.

2. node:start (main.js) must call provisionNode() before it ever checks
   for the service task or spawns -- reversed, the wizard's first Start
   on a fresh service-mode install would run/query the daemon before
   node.toml exists for it to read. Source-read, same technique as
   test_desktop_shell.py: the only evidence available without a live
   Electron run.

Node suite 845 pass / 25 skip.

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

1 files changed, 27 insertions, 0 deletions

diff --git a/packages/meshbay-node/tests/test_packaging_win.py b/packages/meshbay-node/tests/test_packaging_win.py
index 6471446..22ce44b 100644
--- a/packages/meshbay-node/tests/test_packaging_win.py
+++ b/packages/meshbay-node/tests/test_packaging_win.py
@@ -327,6 +327,33 @@ def test_main_js_drives_the_service_task_for_all_three_actions():
         assert "winServiceTaskStatus" in body, f"{handler} never checks for the service task"
 
 
+def test_node_start_provisions_before_it_ever_touches_the_service_task():
+    """
+    On a fresh install with service mode chosen, the Scheduled Task exists
+    before anything is provisioned (node.toml is written by the wizard, not
+    by the installer). node:start must call provisionNode() first and only
+    then ask about the service task / spawn -- reversed, the very first
+    "start" from the wizard would run (or query) an unconfigured daemon
+    instead of the one it just told the caller to expect.
+
+    A bare unprovisioned run is independently proven harmless
+    (test_a_bare_invocation_with_no_config_yet_exits_cleanly in
+    test_cli_dispatch.py), so this is about correctness of *this* call
+    actually starting the daemon the wizard just configured, not about
+    safety if the order were reversed.
+    """
+    main_js = (CLIENT / "src" / "main.js").read_text(encoding="utf-8")
+    body = main_js.split("ipcMain.handle('node:start'", 1)[1]
+    body = body[:body.index("ipcMain.handle(")]
+
+    provision_at = body.index("provisionNode(")
+    service_check_at = body.index("winServiceTaskStatus")
+    assert provision_at < service_check_at, (
+        "node:start checks the service task before provisioning — a fresh "
+        "install's first Start would run/query the daemon before node.toml "
+        "exists for it to read")
+
+
 def test_firewall_ps1_targets_both_executables_and_is_idempotent():
     """One script, both rules — so installer.nsh only ever has to name it
     once on the way in and once on the way out."""