feat: support gateway token passthrough for embedded controllers

[codyhartsook]

Adds app.Options.TokenPassthroughProvider so an embedded controller can deliver tokenPassthrough credentials through the egress gateway, keeping caller tokens out of the actor. Builds on #3177 and #3257. An empty option preserves existing runtime passthrough.

When set:

• Marked MCP and model destinations bind to ate-secret://<provider>/v1/https/<host>:<port>.
• ADK disables runtime token forwarding for marked clients. Claude and Codex accept marked clients with gateway delivery. All render outbound placeholders.
• Shared agents, summarizer models and memory models use the same delivery mode.
• Compilation rejects HTTP destinations, unsupported gateway targets, explicit target-header conflicts and origins shared with unmarked clients.
• A Secret-backed header can coexist with caller-token Authorization on the same MCP client.
• Credential validation accepts external ate-secret provider URIs.

The configured provider resolves credentials and authorizes their use. No CRD, Helm or protobuf changes.

Testing: affected race suites, PostgreSQL credential round-trip tests and lint pass. Live gateway/provider integration, Python execution and cold-start tool discovery remain unverified. The existing TestInstallUsesSeparateSubstrateReleases test fails locally because it reaches a running kagent API.

[EItanya]

🤖 AI-generated review.

I think this is putting the extension behavior too high in the stack. The use case is that we want different behavior on the compiled Substrate EgressPolicy for specific tokenPassthrough origins. However, this threads a provider name through app, the controller, the generic translator, and every harness compiler, then hardcodes the provider URI format in credential compilation.

Could we make EgressPolicy compilation extensible instead? I'm thinking of a simple ordered compiler chain:

type EgressPolicyCompiler interface {
    Compile(context.Context, EgressPolicyInput, *ateapipb.EgressPolicy) error
}

The OSS compiler would always run first and build the normal allowlist and credential effects. Embedded controllers could register additional compilers that run afterward and add their behavior for the relevant origins. The chain would validate the final policy and reject conflicting effects rather than using last-writer-wins.

That would let the generic compilation path keep tokenPassthrough as semantic, origin-scoped information, while the vendor compiler decides how that becomes an EgressPolicy effect. It also gives us a reusable backend extension point without making Claude, Codex, ADK, models, or MCP compilation know about a particular provider or URI protocol.

With that boundary, I don't think we need TokenPassthroughProvider or most of the provider-specific translator and harness changes in this PR.