Avoid exposing API keys in WebSocket query strings

[dreamwing]

API key exposed in WebSocket URL query string

The API key is appended as a plain query parameter to the WebSocket URL. Query parameters appear in server access logs (standard HTTP request-line logging), reverse-proxy/CDN access logs, and network inspection tools.

All other authenticated requests use the x-claw-key header, which does not appear in standard server access log formats. Since the WS upgrade is itself an HTTP request, the header-based approach would work there too — most WebSocket libraries let you pass custom headers via the headers option when the connection originates from a Node.js client.

For browser-based clients where custom upgrade headers are not available, a common approach is a short-lived token handshake: obtain a one-time token from a normal authenticated REST endpoint, then pass only that ephemeral token in the WS query string. This keeps the real credential out of logs entirely.

Originally posted by @greptile-apps[bot] in #23 (comment)

[dreamwing]

Follow-up scope notes:

• Browser WebSocket clients cannot attach arbitrary upgrade headers the way our REST calls attach x-claw-key, so this is not a simple header swap.
• Recommended direction: add a REST endpoint authenticated with the existing x-claw-key that returns a short-lived one-time WebSocket token, then connect the browser WebSocket with only that ephemeral token in the query string.
• The long-lived access key should no longer appear in the WebSocket URL once this is implemented.

Acceptance criteria:

• The long-lived ClawBridge access key is never placed in the WebSocket query string.
• WebSocket auth uses a short-lived token with TTL and single-use or similarly tight replay protection.
• Token expiry / reconnect flows do not break existing dashboard heartbeat and analysis WebSocket behavior.
• This is follow-up security hardening work and is not required to merge PR feat: Cost Control Center #23.