#18273: fix: extract token from URL query string for Control UI websocket auth

When users access the Control UI with a token in the URL query string (e.g., `http://localhost:18789/?token=XXX`), the gateway now extracts the token during websocket upgrade and uses it for authentication. This fixes the issue where the webchat UI fails to connect with "gateway token missing" error even when the token is provided in the URL. ## Changes - `src/gateway/server-http.ts`: Extract token from URL query string during websocket upgrade and attach it to the request object - `src/gateway/server/ws-connection/message-handler.ts`: Use the URL token as a fallback when the client doesn't provide auth in connect params ## Testing - Build passes - Auth tests pass Fixes openclaw/openclaw#18258 Fixes openclaw/openclaw#1690 <!-- greptile_comment --> <h3>Greptile Summary</h3> Implemented URL query string token extraction for Control UI websocket authentication, allowing users to access the UI with a token parameter in the URL. Also fixed webchat session ID generation to use stable UUIDs instead of the per-message `clientRunId`. **Key changes:** - `server-http.ts`: extracts token from URL query params during websocket upgrade and attaches to request - `message-handler.ts`: uses URL token as fallback when client doesn't provide auth in connect params - `chat.ts`: generates stable `sessionId` values and persists to session store (addresses previous thread about `randomUUID()` divergence) **Security considerations:** The PR introduces tokens in URL query strings, which contrasts with HTTP hooks that explicitly block query-string tokens (line 268 in `server-http.ts` warns "query parameters are not allowed"). While URL tokens are less secure than header-based auth (they appear in browser history, server logs, and referer headers), this tradeoff is reasonable for Control UI because: - Control UI already supports `allowInsecureAuth` mode for non-HTTPS scenarios - The token is only extracted during websocket upgrade (not logged in this codebase based on redaction patterns) - This enables break-glass access scenarios mentioned in security docs The implementation correctly uses the existing auth flow and rate limiting. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with low risk - The implementation correctly integrates URL token extraction into the existing authentication flow with proper fallback logic. The session ID fix addresses a real bug. The main concern is the security tradeoff of URL-based tokens (browser history, logs, referer leakage), but this is acceptable for Control UI's use case and aligns with existing `allowInsecureAuth` design. No logic errors or security vulnerabilities identified in the implementation itself. - No files require special attention _{Last reviewed commit: 17b08b9} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->