v1.7.5: read compressed Codex logs

Codex now compresses its older session logs, and Sipcode reads them.

Fixed

• Compressed Codex logs are read. Current Codex compresses older session logs to rollout-*.jsonl.zst and keeps only the newest ones as plain .jsonl. Sipcode skipped the compressed ones, so it saw almost none of a Codex user's history: forecast said it needed more days, limits started again at 0%, and stats, why, today, trend, impact and regress missed most sessions. Sipcode now reads them exactly like plain logs, on Node.js 22.15 or newer (zstd ships in Node's own zlib, so there is no new dependency and still no network). A session with both a plain and a compressed log is read once, from the plain log. A damaged or cut-off compressed log is counted as unreadable, never a crash.
• Older Node.js: a clear warning. On a Node.js without zstd the compressed logs are still counted and reported (see "Logs Sipcode could not read" below). JSON output is unchanged; with --json the note "N compressed Codex log(s) (.jsonl.zst) skipped: reading them needs Node.js 22.15 or newer (you have vX)." goes to stderr.
• regress sandbox warning with --agent. The "could not be read" WARNING told the user to allow read access to both log folders, and with --agent codex it named an empty one ("allow read access to and ..."). It now names only the folders the run read.
• regress --bug-report with nothing to report says so. With no finding, the flag used to print only the plain result, which Codex read as "no output". It now ends with "No bug report: there is no finding to report." The answer was and is always on stdout.

Changed

• Logs Sipcode could not read are impossible to miss. When some log files cannot be read (compressed Codex logs on a Node.js older than 22.15, a damaged or unreadable file, a folder that cannot be listed), stats, today, forecast, trend, impact, why, receipt, drift, limits and regress now start their terminal output with one line per reason, for example "warning: 3 Codex log file(s) could not be read (compressed .jsonl.zst logs need Node.js 22.15 or newer; you have v22.11.0). Numbers below leave them out." It used to be a small note, often the last line and on stderr, and why, receipt and drift did not mention these logs at all. With --json the notes stay on stderr and the JSON is unchanged (stats keeps its warnings array). When every log is read, the output is byte for byte what it was. The four Codex plugin skills say this warning first in their answer.
• Codex plugin: regress checks the Codex logs by default. A first regress over large Claude Code logs can take a minute or more (49 seconds on 5.4 GB on the maintainer's machine; about 1 second once the usage cache is warm), Codex stopped the command after about 10 seconds with empty output, and a sandbox that cannot write ~/.sipcode never warms the cache. When the user asks about Codex or names no tool, the regress skill now runs sipcode regress --bug-report --agent codex (Codex logs only, about 1 second). It reads the Claude Code logs only when the user asks about Claude Code, says first that the run can take a minute or more, and gives the command a timeout of at least 3 minutes. Empty output is never reported as a result.
• README: Node.js 22.15 or newer is needed to read compressed Codex logs.

Notes

• scripts/verify-counts.mjs (the independent counter) reads .jsonl.zst too, decoding it with node:zlib itself, so it cannot agree with a Sipcode that skips them. On the maintainer's frozen logs it matches Sipcode on all 17 Codex logs (15 of them compressed).
• Test count: 2,225 to 2,409 (npx vitest run, which includes the 20 e2e tests).