fix(codex): read rollouts Codex has compressed to .jsonl.zst

[NishantJoshi00]

Issue: #84

What changed and why?

Codex now compresses a rollout it hasn't written to for 7 days, replacing rollout-<ts>-<id>.jsonl with rollout-<ts>-<id>.jsonl.zst. The Codex store matched .jsonl only, so those sessions stopped listing. On my machine that was 781 of 814.

The store now reads both forms.

• discover lists a compressed rollout. It decodes only as far as the header line, so listing stays cheap.
• load decodes the whole file.
• delete accepts a .jsonl.zst path.
• When both forms of one session are on disk, discovery lists the plain one. Codex reads that one too, and the two only coexist for a moment while it compresses or expands a session.
• save is unchanged and writes plain .jsonl.

Decoding uses the zstd crate, the library Codex writes these files with. It was already in Cargo.lock through wreq. It sits behind a new default feature, codex_zstd, because zstd is C and the wasm build can't take it. Anyone building with default-features = false needs to add codex_zstd to keep seeing old Codex sessions.

I checked it against the real sessions on my machine. All 785 compressed rollouts, 2.2 GB plain, load to exactly what their zstd -dc output loads to. Discovering all 819 sessions takes 38 ms. On one thread, loading every compressed session takes 2.6 s, against 1.3 s for the same sessions plain.

One thing I left alone. cargo test -p txcript --no-default-features fails store_delete::antigravity_delete_roundtrip on main today, before this change.

🤖 Generated with Claude Code