feat(packaging): offer one elevated firewall step instead of two dialogs

Installing used to mean clicking through two separate Windows "Allow
access" prompts later — one for MeshBay.exe, one for meshbay-node.exe —
each confusing on its own and worse before the exe carried a version
resource. Adding a firewall rule needs admin, and the installer is
deliberately per-user with no elevation, so this can only ever be opt-in.

packaging/win/firewall.ps1 (new, shipped as an extraResource at
resources\firewall.ps1): idempotent add/remove of the two inbound UDP
rules ("MeshBay", "MeshBay Node"), grouped, logged to
%TEMP%\meshbay-firewall.log. Locates both executables from its own path,
no arguments needed beyond the action.

build/installer.nsh: customInstall asks "Allow MeshBay through Windows
Firewall now?" and runs firewall.ps1 via NSIS ExecShellWait "runas" — one
UAC prompt — only when not ${Silent}; declining or dismissing UAC falls
back to Windows' own per-process prompts, unchanged. customUnInstall
offers the same in reverse, defaulted to No (a stale rule for a deleted
exe is inert, so this should not nag on the way out) and skipped for a
silent uninstall.

Verified: rebuilt MeshBay-Setup-0.1.0.exe (electron-builder compiles the
new LogicLib.nsh / ExecShellWait NSIS successfully); firewall.ps1 run
unelevated fails cleanly into its log ("Access is denied") rather than
silently doing nothing, confirming the fallback path. Node suite 835
pass / 25 skip.

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

1 files changed, 15 insertions, 8 deletions

diff --git a/packaging/win/README.md b/packaging/win/README.md
index 8c29785..7bd7f67 100644
--- a/packaging/win/README.md
+++ b/packaging/win/README.md
@@ -11,6 +11,7 @@ Linux). `meshbay-common` rides along inside the node runtime.
 ├─ 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)
 │  └─ node-runtime\
 │     ├─ meshbay-node.exe          frozen daemon (PyInstaller onedir)
 │     ├─ _internal\ …              its Python + deps (aiortc, av, aioquic, …)
@@ -88,14 +89,20 @@ publish their host candidate as an unresolvable `<uuid>.local` mDNS name that
 `aioice` discards — the browser always dials the node, never the reverse. So the
 node has to accept unsolicited inbound UDP from its peers.
 
-**Windows Defender Firewall.** On the daemon's first run Windows pops a prompt
-for `meshbay-node.exe`. Tick **both Private and Public** — a libvirt/VM adapter,
-and sometimes a plain Ethernet one, registers as Public, and a Private-only rule
-then silently drops every peer. The installer cannot pre-create this rule (it is
-per-user and never elevates); the prompt is the mechanism. If you dismissed it,
-add the rule by hand: *Windows Defender Firewall → Advanced → Inbound Rules →
-New Rule → Program →* the bundled `…\resources\node-runtime\meshbay-node.exe` *→
-Allow → all profiles*.
+**Windows Defender Firewall.** The setup wizard offers to add the inbound rules
+for `MeshBay.exe` and `meshbay-node.exe` in one step — it needs one admin
+confirmation (`build/installer.nsh` runs `firewall.ps1` via NSIS `ExecShellWait
+"runas"`; the per-user install itself never elevates). Say yes and both
+prompts you'd otherwise hit mid-use are gone; say no, or the UAC prompt is
+dismissed, and Windows falls back to its own **"Allow access"** dialog the
+first time each process binds a socket — tick **both Private and Public** then
+(a libvirt/VM adapter, and sometimes a plain Ethernet one, registers as
+Public; a Private-only rule silently drops every peer). Missed both? Add it by
+hand: *Windows Defender Firewall → Advanced → Inbound Rules → New Rule →
+Program →* the bundled `…\resources\node-runtime\meshbay-node.exe` *→ Allow →
+all profiles*. `firewall.ps1` is idempotent and re-runnable
+(`powershell -File resources\firewall.ps1 add`, elevated); it logs to
+`%TEMP%\meshbay-firewall.log`.
 
 **A flat LAN needs nothing else.** The node offers a routable `192.168.x.y` host
 candidate and browsers on the same subnet connect straight to it — same as the