Derive repeatable cache affinity from stable prompt prefixes

Description

The LLM API gateway derives its fallback x-cache-affinity-key from the full
Chat Completions messages value when prompt_cache_key and
x-multi-turn-session-id are absent. The full message list grows on each turn,
so the derived value changes even when requests share a large reusable prompt
prefix. Stargate can then route later turns to a different inference server,
which reduces prefix-cache reuse.

The fallback should represent a stable prompt prefix rather than the complete
request. This is an inference-serving optimization, not a durable conversation
identifier.

Derive a versioned SHA-256 affinity value, such as
mt:v2:prefix:<digest>, from unambiguously encoded fields:

• the authenticated NCA ID
• the stable client authentication identity, never the raw bearer token
• a canonical reusable prompt prefix, including stable system or developer
  context, tool definitions when present, and the first user message

Keep the value deterministic across gateway replicas. Do not expose raw
authentication material or prompt content in router headers, logs, spans, or
metric labels.

Preserve the current precedence of explicit prompt_cache_key,
conversation.id, and x-multi-turn-session-id values. Preserve compatibility
with affinity values returned by earlier gateway versions. Requests that do not
contain a usable stable prefix may retain the current payload fallback and
response-header flow.

Stargate should continue treating x-cache-affinity-key as opaque. No routing
algorithm, chart, CLI, or inference response schema change is required.

Definition of Done

• Chat Completions requests with the same authenticated scope and reusable
  prefix produce the same fallback affinity value as later messages are
  appended.
• A different reusable prefix produces a different affinity value.
• A different NCA or client authentication identity produces a different
  affinity value for the same prefix.
• Prefix extraction handles structured and multimodal message content with a
  documented canonical encoding.
• Explicit prompt_cache_key and x-multi-turn-session-id precedence remains
  unchanged.
• Responses API prompt_cache_key, conversation.id, session-header, and
  payload-fallback behavior remains compatible.
• Previously returned versioned affinity values remain reusable through
  x-multi-turn-session-id without double hashing.
• Raw bearer tokens, authentication identities, and prompt content do not
  appear in downstream affinity headers or telemetry.
• Unit tests cover deterministic derivation, prefix changes, auth-scope changes,
  compatibility, unary requests, streaming requests, and Stargate provider
  forwarding.
• User documentation explains that fallback affinity improves inference-server
  prefix-cache locality and remains best-effort under retry, overload, and
  backend churn.

Resources

• Related issue: https://github.com/NVIDIA/nvcf/issues/822
• Current derivation: src/invocation-plane-services/llm-api-gateway/api/session_affinity.go
• Stargate affinity contract: src/libraries/rust/stargate/docs/load-balancer-configuration.md

Start with src/invocation-plane-services/llm-api-gateway/api/session_affinity.go and read the Stargate contract in src/libraries/rust/stargate/docs/load-balancer-configuration.md. Trace existing precedence, payload fallback, response-header, unary, streaming, and provider-forwarding tests, then define the canonical prefix encoding and versioned digest behavior against the listed compatibility and privacy requirements.