#22818: fix(gateway): allow loopback shared-auth fallback when device token drifts

Prompt Request: Loopback token-drift resilience in gateway auth/pairing Use this prompt to implement and validate the change. You are working in OpenClaw. Goal: Prevent local loopback Control UI lockouts when shared gateway auth is valid but device-token/pairing state has drifted. Context: In some local macOS runs, loopback clients can present valid shared auth (token/password) while device-token/pairing state is stale. Current behavior can fail the connection as unauthorized/pairing-required even though local shared auth is valid. Requirements: 1) Add/ensure loopback shared-auth fallback before device-token hard failure: - If shared auth is valid and request is loopback/local, treat auth as satisfied. - Keep existing non-loopback behavior unchanged. 2) Pairing gate behavior: - For loopback + valid shared auth, bypass hard pairing failure path caused by pairing-state drift. - Preserve normal pairing requirements for non-loopback clients. 3) Scope constraints: - Keep change minimal and localized. - No unrelated refactors. - No workflow/config schema changes. Acceptance criteria: - Reproduced local token-drift scenario no longer locks out loopback client with valid shared auth. - Non-loopback auth/pairing behavior remains unchanged. - Diff is reviewable and tightly scoped. Implementation in this PR: - File: `src/gateway/server/ws-connection/message-handler.ts` - Diff size: single-file, small (`+15/-1`) - Intent: local resilience only, without weakening remote requirements.