feat: add an egress policy translator for embedded controllers

[codyhartsook]

Adds optional app.Options.EgressPolicyTranslator so embedded controllers can bind external credential references to an Agent's existing outbound destinations. Based on #3177.

The shared compiler builds a PolicyDraft from model and MCP inputs, applies the extension, and validates the result before rendering client configuration. Harnesses declare model requirements and consume resolved authentication. The extension can add bindings, but cannot change destinations or requirements, replace existing bindings, or override explicit authentication. Resolved bindings are pinned in the revision and take precedence over conflicting EgressPolicy grants, which admission holds.

Client authentication uses the final model and MCP Secret bindings plus the extension's:

• Supported keyless models receive SDK placeholders, and managed MCP clients receive missing headers. This includes keyless ADK models and native Claude/Codex models.
• Secret-derived bindings also supply missing headers to eligible MCP clients at the same origin. These changes produce new revisions for affected agents.
• Explicit authentication stays protected, including literal Bedrock signing credentials. A configured bearer Secret keeps its binding when signing credentials are also present.
• ADK Bedrock now includes its bedrock-runtime destination, fixing bearer bindings that previously failed compilation.

Extension targets are exact HTTPS model and MCP origins. Keyless Gemini remains deferred. Arbitrary scripts and custom clients must still send the bound header. This adds no CRD fields or credential-provider implementation.

Validation: translator, egress, substrate, app and controller (envtest) race tests pass, as do PostgreSQL revision tests. The pinned linter cannot read Go 1.27 export data. Live provider and gateway integration remains untested.

[codyhartsook]

(removed)

[EItanya]

🤖 AI-assisted design feedback.

I like the idea of letting an embedded controller contribute credentials. Can we make this a shared policy translation step before rendering the harness configuration?

The part that feels coupled is that each harness needs to know about the binder. Codex and Claude check whether it exists to allow a missing key, then CompileCredentials returns both all bindings and a separate additions slice so each harness can patch its MCP configuration afterward. The placeholder string also ends up carrying the meaning “this model requires a gateway binding.” I think those are signs that authentication resolution needs to happen earlier.

What if the flow looked like this:

1. Resolve model, MCP, and EgressPolicy inputs into a common egress draft, building on egress.Access.
2. Apply a policy extension, then validate and normalize the result.
3. Render client configuration from the resolved authentication and persist the resolved grant in the revision.

Conceptually, the extension could look like:

type PolicyTranslator interface {
    Translate(agent types.NamespacedName, draft PolicyDraft) (PolicyDraft, error)
}

The draft would retain the authentication requirements we need during compilation: required header/prefix, existing bindings, and whether explicit authentication prevents additions. Each integration would contribute those requirements where we already understand its behavior. The harness would then consume resolved authentication without needing to distinguish built-in credentials from extension contributions.

We can keep the current restrictions in the shared validation step: no new destinations, no replacement of existing bindings, preserve explicit authentication, and deterministic output. A more general policy interface doesn't need to permit arbitrary changes.

This needs to happen before client configuration is rendered because the gateway only replaces headers the client sends. Updating the final Substrate policy alone wouldn't supply the SDK placeholders or MCP headers. The resolved grant also needs to remain revision-pinned so retries and resume use the same policy.

I think the useful change here is making policy resolution a shared phase with explicit authentication requirements. Putting the current arguments into a Policy struct without changing that flow would leave most of the coupling in place.