Fix two regressions that landed in v0.14.0 which together render the dashboard unusable when fronted by a reverse proxy in --insecure mode.

Changes

1. Restore /api/actions/{name}/status polling in --insecure mode

The SPA polls this endpoint every ~2 seconds to drive the post-update progress modal. In v0.14.0 it started returning 401 through reverse proxies because the endpoint was not covered by the session-token middleware interceptor — POST /api/hermes/update (the kickoff) carried the header correctly, but the status poller did not.

Fix: add /api/actions/{name}/status to PUBLIC_API_PATHS in hermes_cli/dashboard_auth/public_paths.py. The response is read-only and only exposes ~/.hermes/logs/<action>.log, which the operator already has shell access to.

2. Restore WebSocket access from reverse-proxy IPs in --insecure mode

In --insecure mode _ws_client_is_allowed() was locking all WS endpoints (/api/ws, /api/events, /api/pty) to loopback IPs only. The operator chose --insecure precisely because they're terminating auth at the proxy layer (SSO, mTLS, basic auth, etc.), and the WS arrives from the proxy's IP, not 127.0.0.1. The existing ?token= constant-time check in _ws_auth_ok is the same protection used on every authed HTTP endpoint, which is not similarly IP-restricted.

Fix: in _ws_client_is_allowed(), respect the allow_public flag (--insecure mode) and skip the IP check when it is set, relying on the ?token= check as the sole auth gate for WS in that mode.

Both changes are minimal and targeted — no architecture changes, no new dependencies.

Closes #34227