fix(proxy): make wrapper auth actually work with current openclaw Control UI

[cap10bad]

Summary

Four related auth fixes that are needed together for the wrapper to work correctly with the current Control UI (openclaw >= v2026.4.24). Originally opened for the first bullet only; extended after verifying end-to-end on a live deployment surfaced the rest.

1. Authorization: Bearer always overwrites Basic before proxying

attachGatewayAuthHeader had a !req?.headers?.authorization guard. Once the browser cached Basic creds for the dashboard, every subsequent proxied request leaked Basic <SETUP_PASSWORD> to the gateway and was rejected as a token mismatch. Drop the guard — when OPENCLAW_GATEWAY_TOKEN is set, always rewrite Authorization to Bearer <token> before the proxy call. PR #164 addressed the WS path; this covers HTTP.

2. Bootstrap the gateway token into Control UI localStorage

openclaw v2026.4.24 changed the Control UI auth protocol: the gateway token is now read from localStorage["openclaw.control.settings.v1"].token and sent inside the WS handshake message payload, not the HTTP Authorization header. The wrapper's proxy-level header injection is invisible to the new auth path — connect fails with reason=token_missing and the gateway prints "paste the token in Control UI settings".

On the first GET / after dashboard auth, serve a tiny bootstrap HTML that writes GATEWAY_TOKEN into localStorage, sets a 1-year oc_wrapper_bootstrapped cookie, and reloads. Subsequent loads go straight to the Control UI with auth already resolved client-side. Token never leaves the authenticated dashboard trust boundary.

3. Accept Authorization: Bearer <GATEWAY_TOKEN> on the wrapper itself

requireDashboardAuth previously only accepted Basic, so API/CLI clients already holding the gateway token were forced through the browser Basic prompt. Now accept Bearer (timing-safe compare) and advertise both schemes in WWW-Authenticate. Bearer passes through to the gateway unchanged.

4. Replace native Basic popup with a styled HTML login + session cookie

The browser's native Basic auth dialog is jarring for a production dashboard. On GET with Accept: text/html and no session, return an HTML login page. POST /__login validates SETUP_PASSWORD and sets an HMAC(SETUP_PASSWORD) session cookie (30-day, HttpOnly, Secure, SameSite=Lax) — stateless, invalidates automatically on password change. Basic/Bearer still accepted for curl/CLI clients; successful Basic auth also sets the cookie.

Test plan

• Existing test suite (12 tests including websocket-upgrade-auth) passes
• Deployed live to a Railway instance — dashboard auth → Control UI → gateway WS all work without manual token paste
• curl -H "Accept: text/html" / returns login page (no WWW-Authenticate: Basic challenge)
• curl / (no Accept) returns WWW-Authenticate: Basic ..., Bearer ... (unchanged for scripts)
• curl -H "Authorization: Bearer <GATEWAY_TOKEN>" / succeeds
• After login, session cookie persists for 30 days; clearing site data shows login page again