[Feat] Add owner-approved API keys to Fast Sessions

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

No linked issue; this is a scoped prototype.

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

Allow a Fast Session to use an explicitly approved API key without asking the human to paste credentials into chat or exposing the key to model tools or sandbox workers.

What changed

• Add nonsecret preparation and discovery tools. The primary approval form shows a service title, exact HTTPS destination, the existing secure API-key Input, and Allow for this Session. The button is the explicit approval action; there is no checkbox or technical-details disclosure in the entry form. Default HTTPS port 443 is omitted, while non-default ports remain visible. Header, prefix, and expiry are available separately in Manage approved secrets.
• Saving atomically approves the immutable prepared policy and resumes the same Session server-side with nonsecret context when continuation is available. Loading, selection, and typing do not approve. The key and reveal state are cleared on submission, request changes, close, and revocation.
• Use one API-owned HTTP broker for dynamic Session grants and operator-manifest integrations. Remove the duplicate SDK request transport; upstream credentials stay in the control plane, not model arguments or worker environments.
• Bind Fast access through short-lived ES256 broker-only tokens from trusted human turns to the live persisted conversation and canonical Session. Bind coding-run access through unique persisted task attachments and the live acting owner. Recheck attachment, ownership, expiry and revocation before dispatch and before response release, including after completion audit persistence. Caller-supplied Session IDs and unscoped user tokens do not confer Session-grant authority.
• Keep Session requests GET/HEAD-only on the exact approved public HTTPS origin and port, with a 10-second deadline, 64 KiB response cap, guarded DNS, redirect refusal, and suppression of exact/common encoded credential echoes. Omitted, null, and empty-string GET/HEAD bodies all mean no body. Audit records remain metadata-only and secret-entry telemetry is excluded.
• Mount dynamic Session grants without requiring a static manifest or per-service credential environment variables, even with operator mode disabled. Explicit operator opt-in still requires valid configuration and fails startup closed if configuration is missing or malformed. Existing deployment encryption and signing keys are reused.
• Retain additive migrations 0079/0080, tests, public documentation and a changeset. This combined refresh introduces no new migration. No Iron dependency.

Impact and limits: Session approval is not OAuth, a general HTTP proxy, POST/body support, worker secret injection, or a usage-quota system. Operator integrations retain their separately configured method/path rules. Session approval covers all paths on the exact origin and port. A trusted upstream receives the key and can misuse its privileges or return transformed/partial secret data; key concealment cannot eliminate those risks. Use least-privilege credentials.

Related PRs

Depends on #2384: HTTP integration broker at exact commit b732e37440b259c7046b699305eb8f3f91c9795f. That dependency is incorporated in this branch; the PR base remains develop. The dependency's operator-only validation does not establish readiness of the combined Session-grant feature.

Combined feature commit: e61718260e33f3c13b16cd91d9e0ea9e59e9d0ac.

How it was tested

• Combined implementation validation reported 878 passing automated tests: API 177, Fast 465, SDK 59, auth 13, worker 60, and web 104. Eight-package type checks, lint and docs validation passed. Six earlier API expectation-fixture failures were corrected rather than skipped, and dynamic-mode coverage was added. These results are carried from implementation, not a delivery rerun of the test suites.
• This delivery passed normal pre-commit formatting and the full pre-push gate: oxlint, web/worker ESLint, 27 package type checks, and knip. Non-failing tooling notices remain for a package dependency cycle and an unused knip ignore entry.
• Automated checks only. Browser proof, model-driven tests, end-to-end execution and compute validation were explicitly deferred. No screenshot or end-to-end proof is claimed for this combined commit; final readiness remains a separate review decision.

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

The prototype is one feature but spans storage, execution and UI; generated migration snapshots account for most added lines. A checked-in changeset is included.

[roomote-community]

No new code issues found. See task

• apps/web/src/components/sessions/SessionSecrets.client.test.tsx:62 Escape the literal hostname dots in the consent-origin assertion.

_{Reviewed f646601}