[feature] Decide where trusted request context should live

[afourniernv]

Problem

A Rust host embedding Switchyard may authenticate a request before routing and need to carry trusted request-scoped state, such as a tenant ID or authorization decision, through routing and request clones. That state should not come from client headers or be forwarded to an upstream model.

PR #578 puts an http::Extensions type map on protocol Metadata. PR #580 adds server ingress hooks that could populate it. Before changing the released protocol type, we should decide which layer owns this state.

Proposed solution

Agree on the ownership and public API first, then use #578 as the implementation if Metadata is the right boundary.

Questions to settle:

• Should trusted context live in protocol Metadata, the runner, or the server/host layer?
• Does it need to reach algorithms and clients, or only ingress and response hooks?
• Should Switchyard expose http::Extensions directly?
• If it belongs in Metadata, should it wait for the next breaking protocol release?

Alternatives considered

• Keep the context in server-owned ingress state and pass it only to response hooks.
• Add an opaque runner-owned request context instead of exposing http::Extensions from the protocol crate.
• Use existing string metadata. This is less suitable for trusted typed values and makes ownership less clear.

Scope notes

• Related implementation: feat(protocol): add typed request context #578
• Related ingress hooks: feat(server): add composable ingress hooks #580
• Adding a field to public Metadata is source-breaking for downstream struct literals and exhaustive patterns.
• This is a Rust embedding API decision; it does not change the wire format.

Additional context

The immediate use case is an embedded host authenticating a request, attaching trusted state, and retaining it while Switchyard routes or clones the request.

[ilexpoon]

I validated the embedding requirement against the consuming gateway. The trusted context must:

1. be created during server ingress before the request body is buffered;
2. survive conversion into the provider-neutral Request and any request clones;
3. remain available after algorithm routing;
4. be readable by the selected RoutedLlmClient;
5. remain available to response presentation; and
6. never enter client-controlled headers, provider payloads, or normal logs.

A server-only extension would not satisfy point 4 without a broader change to the runner, route, algorithm, and client trait signatures.

My preferred direction is therefore a protocol-owned but opaque typed context carried with the request. Switchyard would expose typed insert/get methods rather than exposing http::Extensions directly. Because adding the field is source-breaking, this should ship in the next breaking protocol release; that release could also make Metadata non-exhaustive to avoid repeating this problem.

I will keep #578 in draft until the team agrees on this boundary.