fix: support retrieval of stored Responses payloads

[franciscojavierarceo]

Summary

A response created with store: true could be continued through previous_response_id, but retrieving it with GET /v1/responses/{response_id} returned 404. Add an authenticated retrieval route backed by a typed terminal response snapshot, persisted atomically with the response history. Retrieval preserves this turn's output, status, usage, and IDs without calling the upstream model.

Keep snapshots out of continuation checkpoints and strip request-scoped MCP credentials before persistence. Unknown IDs return a JSON 404; legacy and history-only records return 409 because they lack the original response payload. Document the behavior and expose the endpoint in OpenAPI.

When OIDC is disabled and OPENAI_API_KEY is nonempty, retrieval validates the supplied bearer token locally before reading storage. Missing or invalid credentials return 401; OIDC authentication takes precedence when enabled. Deployments without either authentication option retain unauthenticated access.

Test Plan

• Reproduced the missing-route regression: the retrieval test expected 200 and received 404 before enabling the route.
• Run server integration suites for retrieval, incomplete responses, HTTP responses, WebSockets, OpenAPI, OIDC authentication, and conversations.
• Verify missing, invalid, and valid API keys, OIDC precedence, and retrieval with the upstream offline.
• Run core unit tests and storage integration tests, including credential sanitization and continuation budgets.
• Run cargo clippy --workspace --all-targets -- -D warnings and all pre-commit hooks.
• Live-tested Qwen3.8-27B-FP8 through a separate local gateway: two stored turns round-tripped exactly through GET, and an unknown ID returned JSON 404. Automated tests additionally verify retrieval after gateway restart and with the upstream unavailable.

[maralbahari]

@franciscojavierarceo could you please fix the ci and resolve merge conflict?