feat(dashboard): opt-in LAN WebSocket access via HERMES_DASHBOARD_TRUST_LAN

[InphinitiZ]

Summary

Allows opt-in LAN access to dashboard WebSocket endpoints via the new HERMES_DASHBOARD_TRUST_LAN environment variable. Default behavior is unchanged — strict loopback-only as introduced in #30741.

Motivation

Reverse-proxy deployments where Hermes dashboard runs behind a separate gateway host (e.g. router/firewall doing TLS termination + auth on a different LAN machine) currently hit 4403 on all four WebSocket endpoints (/api/events, /api/ws, /api/pty, /api/pub) because ws.client.host is the proxy's LAN IP, not loopback. PR #18633 previously addressed this with --insecure + 0.0.0.0; PR #30741 tightened it back to loopback-only. This change re-enables the use case as an explicit opt-in without weakening the default.

Behavior

• Env unset / 0 / false (default): unchanged — only loopback clients accepted, public IPs rejected.
• Env 1 / true / yes: RFC1918 (10/8, 172.16/12, 192.168/16) and ULA (fc00::/7) clients additionally accepted; public IPs still rejected.
• Loopback always allowed regardless of env.
• Host/Origin header check (_ws_host_origin_is_allowed) is unaffected.

Security note

Operators enabling this must ensure their LAN segment is trusted and that the reverse proxy enforces authentication. This is opt-in precisely because LAN ≠ trusted in many deployments.

Tests

Four new test cases cover loopback / LAN-default-reject / LAN-with-env-allow / public-IP-still-rejected.

[alt-glitch]

Related to #32615 (dashboard WS fails through Cloudflare Tunnel) and competing PR #32614 (allow WS for public binds). This PR takes a different approach: opt-in LAN trust via env var, keeping loopback-only as default.

[alt-glitch]

This was generated by AI during triage.

Related: #33099 addresses the same dashboard remote-WebSocket gap (it via HERMES_DASHBOARD_ALLOW_REMOTE_WS, this via HERMES_DASHBOARD_TRUST_LAN with RFC1918/ULA scoping). Two competing opt-in approaches for the same reverse-proxy/container use case — maintainer should pick one.

[teknium1]

Thanks for the narrowly scoped implementation and the RFC1918/ULA test coverage.

This automated hermes-sweeper review is closing it under the standing configuration policy:

• The PR adds HERMES_DASHBOARD_TRUST_LAN, a user-facing non-secret feature flag for WebSocket peer access (hermes_cli/web_server.py, PR commit 0171561a18bd).
• The contribution rubric explicitly rejects new HERMES_* environment variables for behavioral configuration; those settings belong in config.yaml (AGENTS.md:102-107).
• Current main supports the remote-dashboard use case through an authenticated non-loopback bind: gated WebSockets allow peers (hermes_cli/web_server.py:14360-14361), and non-loopback startup fails closed unless an auth provider is configured (hermes_cli/web_server.py:17030-17078). The documented setup uses --host 0.0.0.0 with dashboard authentication (website/docs/user-guide/features/web-dashboard.md:142-166).

If a constrained reverse-proxy setting remains desirable, please re-scope it to the documented config.yaml mechanism and the existing authenticated non-loopback deployment path rather than adding a .env feature flag.

---

Closed as not-planned per standing maintainer policy (env-var-for-config). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.