fix(oauth): route zed-hosted native-app callback back to the dashboard port

[phatchau036]

Summary

• The zed-hosted provider's native-app sign-in always redirects the browser to http://127.0.0.1:<native_app_port>/?user_id=...&access_token=.... That port was the hardcoded default 58443, so after signing in at zed.dev the browser lands on a dead port ("site can't be reached") and the login looks broken — even though the access token is right there in the URL.
• The manual paste fallback could never complete either: handleManualSubmit requires a ?code= param that Zed's callback never carries, so pasting the URL always failed with "No authorization code found".
• This PR derives native_app_port from the dashboard's own loopback port so the redirect lands back on OmniRoute, forwards the root / query to the /callback relay, teaches the relay to recognize the Zed payload, and fixes the manual paste path for zed-hosted.

Flow after the fix (true localhost): Connect → popup at zed.dev → Zed redirects to 127.0.0.1:<dashboard-port>/?user_id=...&access_token=... → root handler forwards to /callback → relay postMessages the full URL → modal exchanges it (RSA-decrypts with the authorize-time private key) and saves the connection. LAN/remote deployments keep the dead-port redirect and the (now working) manual paste flow.

Related Issues

• No existing issue found for this failure mode (searched "zed oauth" / "zed-hosted"); happy to link one if it exists.

Validation

• Change type: provider / UI
• Focused tests and category gates from the golden path — not run locally (authoring machine could not install node_modules); CI on this PR runs them
• npm run lint — not run locally (same reason)
• Reconciled with the current active release base — branched from main @ ca23eed; all six touched files verified byte-identical to that base before editing
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• tests/unit/ui/oauth-callback-postmessage-scope.test.tsx — trusted-origin set extended with the loopback same-port variants (http://localhost:<port> / http://127.0.0.1:<port>), keeping the feat: WebSocket proxy support on /v1/responses for Codex CLI compatibility #998 no-wildcard guarantee assertions intact.

Coverage Notes

• The /callback relay origin change is covered by the updated postMessage scope test. The buildAuthUrl port derivation and the modal paste-path dispatch are exercised by the existing zed/oauth-modal suites in CI; no dedicated new unit test asserts the port derivation yet (noted below).

Reviewer Notes

• Root-cause trace: createZedNativeAuthData always sends native_app_port (default 58443) and Zed ignores any redirect_uri/path, redirecting to the loopback root. Separately, the root page (/) 307-redirects to /dashboard and drops the query string, so even landing on the dashboard port would have lost the payload — hence the forward-to-/callback handler.
• resolveDashboardLoopbackPort only accepts http: loopback redirect URIs; https/remote/LAN origins keep the old default port and the paste flow, so no remote behavior changes.
• The loopback same-port additions to trustedTargetOrigins are both spellings of the operator's own machine on the same port (localhost vs 127.0.0.1) — the same rationale as the existing 1455 entries; a hostile local app would be on a different port and still never receives the code.
• All six files transpile cleanly (esbuild parse check). End-to-end against live zed.dev was not possible from the authoring machine — a maintainer smoke-test of a real zed-hosted connect on localhost would be the last mile.