feat(packaging): cover LAN casting in the Windows firewall step, too

firewall.ps1 only handled WebRTC. The cast HTTP relay (src/cast-relay.js,
fixed TCP 19550-19553) and Chromecast/Smart TV mDNS discovery
(src/cast-chromecast.js, bonjour-service, UDP 5353) are a separate surface
on the client and were still hitting Windows' own "Allow access" dialog.

Now four named rules: MeshBay / MeshBay Node stay program-scoped with no
port restriction (there is no fixed WebRTC port to name -- the Windows
equivalent of the broad 1024-65535/udp range the Linux packaging needs,
since netfilter has no program scoping); MeshBay Cast / MeshBay Cast
Discovery add the program AND the fixed port, matching
packaging/firewall/*/meshbay-cast.xml exactly.

test_packaging_win.py cross-checks the port numbers against cast-relay.js's
own constants and the Linux firewalld definition, so the three descriptions
of one port range can't quietly drift apart.

Verified: rebuilt MeshBay-Setup-0.1.0.exe; the deployed firewall.ps1 carries
all four rules. Node suite 836 pass / 25 skip.

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

1 files changed, 29 insertions, 12 deletions

diff --git a/packaging/win/README.md b/packaging/win/README.md
index 7bd7f67..5130e60 100644
--- a/packaging/win/README.md
+++ b/packaging/win/README.md
@@ -89,18 +89,35 @@ 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.** 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
+**Windows Defender Firewall.** The setup wizard offers to add four inbound
+rules 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):
+
+| Rule | Program | Protocol / port | For |
+|---|---|---|---|
+| `MeshBay` | `MeshBay.exe` | UDP, any port | WebRTC (ICE checks touch the client too) |
+| `MeshBay Node` | `meshbay-node.exe` | UDP, any port | WebRTC (the node — unsolicited inbound, see above) |
+| `MeshBay Cast` | `MeshBay.exe` | TCP 19550–19553 | LAN cast HTTP relay (`src/cast-relay.js`) |
+| `MeshBay Cast Discovery` | `MeshBay.exe` | UDP 5353 | Chromecast/Smart TV mDNS discovery (`bonjour-service`) |
+
+The WebRTC rules have no port restriction because there is no fixed port to
+name — aiortc binds a fresh one per connection — so they are scoped by
+*program* instead, which is the Windows-native answer to the same problem the
+Linux packaging solves with a broad `1024-65535/udp` range
+(`packaging/firewall/`). The cast rules are scoped by program *and* port,
+since those two are fixed and known — matching
+`packaging/firewall/*/meshbay-cast.xml` exactly.
+
+Say yes and every prompt you'd otherwise hit mid-use — connecting, or the
+first cast — is gone. Say no, or the UAC prompt is dismissed, and Windows
+falls back to its own **"Allow access"** dialog the first time each
+program/port combination is used — 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 one? Add it by hand:
+*Windows Defender Firewall → Advanced → Inbound Rules → New Rule → Program →*
+the exe *→ Allow → all profiles*, restricting to the port above if it is a
+cast rule. `firewall.ps1` is idempotent and re-runnable
 (`powershell -File resources\firewall.ps1 add`, elevated); it logs to
 `%TEMP%\meshbay-firewall.log`.