fix: pin responses encrypted content affinity

[shudonglin]

Summary

• stop Responses fallback chains on Azure invalid_encrypted_content errors
• apply fallback key pinning after fallback context clearing
• remember Azure Responses previous_response_id and encrypted-content affinity to the selected key
• reuse cached affinity before normal key rotation for Responses continuations
• add unit coverage for fallback stopping, fallback key pinning, response-id affinity, encrypted-content affinity, and affinity writes

Root cause

Azure Responses encrypted content is bound to the Azure deployment/key that produced it. Bifrost could rotate or fall back to a different Azure key on a later Responses request, then Azure rejected the continuation with invalid_encrypted_content because that key could not decrypt the state.

Validation

• go test ./... in core/
• gofmt
• git diff --check

Notes

The cache uses the configured Bifrost KV store. In a multi-instance deployment without KV sync, affinity can still miss when a continuation lands on another instance. The paired infra PR enables Cloud Run session affinity for prod Bifrost to reduce that risk, and a durable/shared KV backend would be the stronger long-term fix.

[shudonglin]

Post-merge review note from the gateway release pass.

Reviewed as part of the production deployment verification. CI passed before merge, the Bifrost image was built and deployed successfully, production Terraform converged, live Cloud Run traffic is on the merged Bifrost image tag, and post-deploy smoke/log checks passed. No follow-up blocker found in this PR during release verification.