fix(codex): preserve Fast routing through dedicated kernel

[gorquan]

Problem

Codex /v1/responses requests reached vm2api with service_tier and client routing metadata, but the previous kernel dropped the headers and did not preserve the Fast routing signal on the final ChatGPT request.

Changes

• Add a dedicated Go kin-codex-kernel implementation for the Unix-socket Codex hop.
• Preserve the supported Codex compatibility headers through an explicit allowlist.
• Emit x-codex-routing-hint: model=<model>;tier=<tier> and map service_tier: "fast" to the ChatGPT wire value "priority".
• Attach the selected OAuth bearer token and ChatGPT account id inside the kernel, while filtering client authorization headers.
• Forward upstream SSE responses and support credential refresh, proxy enforcement, health, and cancellation endpoints.
• Build and test the kernel in CI and build the stripped Linux amd64 binary into release images.

Validation

• Go kernel: go test -race ./..., go vet ./..., and Linux amd64 build passed.
• Changed Codex Node tests passed (codex-convert, handle-codex, codex-kernel-client, vm-test-chat-codex).
• Full Node unit run reached 3 pre-existing environment-dependent failures in unrelated egress/self-inspection/OAuth tests; no changed Codex test failed.
• On the test host, built vm2api:codex-fast-routing-v2, replaced the vm2api container while preserving its mounts and slot containers, verified the image and bind-mounted kernel hashes match, and confirmed a live /v1/responses request with service_tier=priority returned HTTP 200 after restart.

[dofastted]

Superseded by #222. The Go rewrite rejects socks5/socks5h (control plane writes socks5h URLs) and drops the existing Rust hop (WS, quota headers, scheduler). Fast routing is handled on the current kin-codex-kernel instead.