[feature] Decide where trusted request context should live

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: #578
• Related 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.

Start by reviewing related implementation #578 and the ingress hooks in #580, then compare whether trusted request context belongs in protocol Metadata, the runner, or the server/host layer. Done means the ownership, exposure, and release strategy are agreed, with the chosen public API and any follow-up implementation clearly recorded.