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>

2 files changed, 42 insertions, 4 deletions

diff --git a/packages/meshbay-client/build/installer.nsh b/packages/meshbay-client/build/installer.nsh
index 15a840f..67d103d 100644
--- a/packages/meshbay-client/build/installer.nsh
+++ b/packages/meshbay-client/build/installer.nsh
@@ -1,9 +1,11 @@
 ; electron-builder NSIS customisation (auto-included: build/installer.nsh).
 ;
-; Per-user install, no elevation (package.json build.nsis). This does two things
-; beyond the default: put the bundled daemon on the user's PATH so `meshbay-node`
-; works in a terminal, 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). 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).
 ;
 ; Deliberately NOT touched:
 ;   - %LOCALAPPDATA%\meshbay\  (node.toml, keystore.enc, unlock.key, data/) --
@@ -12,9 +14,12 @@
 
 !include "WinMessages.nsh"
 !include "WordFunc.nsh"
+!include "LogicLib.nsh"
 !insertmacro WordAdd
 !insertmacro un.WordAdd
 
+!define MB_PWSH "$SYSDIR\WindowsPowerShell\v1.0\powershell.exe"
+
 ; The dir electron-builder drops resources into. `meshbay-node.exe` and its
 ; frozen Python live directly in here. A fixed suffix of $INSTDIR, so both the
 ; add (install) and the remove (uninstall, where $INSTDIR is still known) match
@@ -34,6 +39,21 @@
   ${WordAdd} "$0" ";" "+${MB_NODE_BIN}" $1
   WriteRegExpandStr HKCU "Environment" "Path" "$1"
   SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000
+
+  ; Firewall. MeshBay.exe and meshbay-node.exe each bind UDP sockets for WebRTC,
+  ; 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 to
+  ; run one elevated helper now: one UAC prompt instead of two dialogs mid-use.
+  ; firewall.ps1 is idempotent and does nothing if the exes are missing.
+  ${IfNot} ${Silent}
+    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
+      ExecShellWait "runas" "${MB_PWSH}" \
+        '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" add' \
+        SW_HIDE
+    mb_skip_fw:
+  ${EndIf}
 !macroend
 
 !macro customUnInstall
@@ -45,6 +65,20 @@
   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.
+  ${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
+      ExecShellWait "runas" "${MB_PWSH}" \
+        '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" remove' \
+        SW_HIDE
+    mb_keep_fw:
+  ${EndIf}
+
   ; meshbay_node.platform._startup_vbs() -- if the user ran "meshbay-node
   ; autostart install" (or toggled it in the client), this points wscript at
   ; the binary we are about to delete, and would error at every sign-in.
diff --git a/packages/meshbay-client/package.json b/packages/meshbay-client/package.json
index 57acff8..7f5afcb 100644
--- a/packages/meshbay-client/package.json
+++ b/packages/meshbay-client/package.json
@@ -33,6 +33,10 @@
           "from": "node-runtime",
           "to": "node-runtime",
           "filter": ["**/*"]
+        },
+        {
+          "from": "../../packaging/win/firewall.ps1",
+          "to": "firewall.ps1"
         }
       ]
     },