security(relay): minor hardening follow-ups from PR review

- Uniform auth responses remove the session-enumeration oracle: unknown
  session and wrong password now return an identical 401 at the API layer and
  an identical WS handshake/close; desktop-status and the 503 "not connected"
  signal are only exposed after successful auth.
- Session-count cap re-checked after bcrypt.hash so concurrent creates can't
  overshoot maxSessions.
- Relay web client reconnect backoff resets only after a successful auth
  response (an accept-then-close server no longer defeats the backoff).
- idGenerator comment corrected to match the rejection-sampling; drop unused
  recordFailure return value.
- DEPLOY.md: document ALLOWED_ORIGINS for reverse-proxy deployments.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

macropad-relay/DEPLOY.md

@@ -80,6 +80,19 @@ Set these in your container configuration:
 - `DATA_DIR` - Data storage path (default: ./data)
 - `NODE_ENV` - production or development
 - `LOG_LEVEL` - info, debug, error
+- `ALLOWED_ORIGINS` - Comma-separated list of allowed browser origins for the
+  WebSocket Origin check (e.g. `https://macropad.example.com`). **Set this to
+  your public origin(s) when running behind a reverse proxy** (see note below).
+
+> **Reverse proxy note (`ALLOWED_ORIGINS`):** When `ALLOWED_ORIGINS` is unset,
+> the WebSocket upgrade Origin check falls back to comparing the browser's
+> `Origin` host against the raw `Host` header seen by the app. Behind a reverse
+> proxy the internal `Host` (e.g. `localhost:3000`) often differs from the
+> public origin the browser sends (e.g. `https://macropad.example.com`), so
+> legitimate browser WebSocket upgrades get **rejected**. Set `ALLOWED_ORIGINS`
+> to your public origin(s) to fix this. (Forwarding the public host via
+> `proxy_set_header Host $host;`, as in the Nginx example below, also helps, but
+> setting `ALLOWED_ORIGINS` explicitly is the reliable fix.)
 
 ## Test It Works