Consolidate Responses API Codex metadata

[owenlin0]

Why

Responses API request instrumentation is the source of truth for downstream Codex analytics that join requests by Codex IDs such as session, thread, turn, and context window. Before this change, those values were assembled through several request-specific paths: HTTP request bodies, websocket handshake headers, websocket response.create payloads, compaction requests, and the rich x-codex-turn-metadata envelope all had their own wiring.

That made metadata propagation easy to drift across API-key/direct Responses API requests, ChatGPT-auth/proxied requests, websocket requests, and compaction requests. It also made additions like window_id error-prone because a field could be added to one transport projection but missed in another.

What changed

• Added CodexResponsesMetadata as the core-owned snapshot for Codex metadata sent to ResponsesAPI.
• Render client_metadata["x-codex-turn-metadata"], flat client_metadata projections, and direct compatibility headers from that same snapshot.
• Include the known Codex-owned fields in the turn metadata blob, including installation/session/thread/turn/window IDs, request kind, lineage, sandbox/workspace metadata, timing, and compaction details.
• Treat app-server responsesapi_client_metadata as enrichment for the Codex turn metadata blob while preventing those extras from overriding Codex-owned fields.
• Use the same metadata path for normal turns, websocket prewarm, local compaction, remote v1 compaction, and remote v2 compaction.
• Keep websocket connection-only preconnect metadata separate so handshakes carry compatibility identity headers without inventing a fake turn metadata blob.

Verification

• cargo check -p codex-core
• just fix -p codex-core