[Feat] Restrict Iron credential requests to allowed origins

[roomote-roomote]

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

What changed

• Add R_SESSION_EGRESS_ALLOWED_ORIGINS, a bounded JSON list of canonical exact HTTPS origins for Iron-backed Session egress. Empty or unset configuration denies all destinations.
• Intersect the deployment list with owner-approved grants both before substitute issuance and on every live authorization. Each real credential and rses_ substitute remains bound to one grant and one origin even when a workload uses several allowed origins.
• Reject malformed, wildcard, deceptive, credential-bearing, path/query/fragment, IP-literal, zero-port, duplicate, and non-HTTPS configuration entries. Existing effective-port, method, revocation, expiry, authority, public-address, redirect, and credential-reflection protections remain in force.
• Keep the policy variable out of worker environments and document the API-only Compose/operator configuration and its scope.

Why this change was made

Owner approval already constrained each substitute to one exact origin, but deployments had no independent list of destinations permitted to use Iron credential substitution. This adds that operator ceiling without widening one credential across several sites or turning Session egress into sandbox-wide network policy.

Impact

Only requests that present an Iron Session-egress substitute are affected. The separate HTTP integration broker and unrelated outbound requests are unchanged. Tightening the list immediately denies existing substitutes at the next authorization boundary; newly disallowed grants receive no new substitute.

Validation

• @roomote/api Session-egress test: 56 passed against the real test database, including empty-list denial, withheld issuance, two exact origins with distinct substitutes, non-default port binding, and live policy tightening without credential release.
• @roomote/env test: 90 passed, including canonical default-port handling, explicit port-zero rejection, and rejection of unsafe or ambiguous list entries.
• @roomote/sdk Session-egress integration test: 14 passed against the real test database after configuring its synthetic origins explicitly.
• @roomote/compute-providers worker-env test: 24 passed.
• bash build.sh test: passed the actual pinned Iron pipeline under Go race detection using generated synthetic PKI/credentials and local TLS servers. The allowed fixture observes the substituted credential; the denied fixture fails if its upstream is contacted, and redirect destinations are stripped and not followed.
• bash build.sh vet, bash build.sh build, and bin/session-egress-gateway version: passed at pinned Iron commit 2393dd175a8c419153fb49917fdeceb94cd9ed59.
• affected package TypeScript checks, pnpm lint:fast, pnpm check-types:fast, pnpm knip, docs validation/link checking, Compose overlay test, and repository pre-push gates passed.

The Iron fixture executes the real pinned gateway with a local authorization double; the API test executes the real authorization/database path separately. This does not claim a full Roomote-created Docker sandbox, cloud-provider, or live external-service run.

A full local pnpm test run advanced past the original SDK failure but reported one unrelated Brain count assertion from the newly advanced develop base; that exact test passes when run alone.

[roomote-community]

No new code issues found. See task

• Reject port zero in the Session-egress origin allowlist (packages/env/src/index.ts:113).

_{Reviewed 3c41885}

[roomote-roomote]

Fixed the port-zero allowlist finding and restored the SDK Session-egress integration fixture in 3c41885f. The review thread is resolved, and both the Roomote code review and Test checks now pass. See the review task.