fix: allow WSL2 172.x subnet in CORS origin whitelist

[web3dev1337]

Summary

• Adds http://172. to the Socket.IO CORS origin whitelist
• WSL2 uses a 172.x.x.x virtual network — browsers connecting via the WSL IP were rejected by the CORS policy added during public-release security hardening

Test plan

• Access orchestrator from Windows browser via WSL2 IP (e.g. http://172.30.127.227:2080)
• Verify Socket.IO connects without 400 errors

🤖 Generated with Claude Code

[web3dev1337]

Reviewed in the open-PR sweep: right idea, but bare http://172. matched all of 172.0.0.0/8 — including public ranges like Cloudflare's 172.64/13 and Google's 172.217/16 — not just WSL2's private 172.16.0.0/12. Tightened to /^http:\/\/172\.(1[6-9]|2\d|3[01])\./. Note the pre-existing 100. prefix has the same imprecision (all of 100/8 vs CGNAT 100.64/10) — left for a follow-up since it's on main already. Good to merge after this.

[web3dev1337]

Extended for remote access: the whitelist now also accepts the remaining RFC1918 private ranges (192.168/16, 10/8) — LAN devices reaching the orchestrator through the Windows portproxy present origins like http://192.168.0.53:2080, which were being rejected so Socket.IO never connected from a phone or second PC. Public address space remains blocked.