fix(codex): detect resumed Windows Codex sessions stored under a previous date (#153)

[aznikline]

Summary

Closes #153. On Windows, abtop could miss an active Codex CLI session that was resumed on a later date than the one it was created on, because the Codex collector's Windows fallback scanned only today's ~/.codex/sessions/YYYY/MM/DD/ directory.

A resumed Codex session keeps writing the rollout file created on the original date — e.g. a session started 2026/07/07 and resumed on 2026/07/08 still appends to ~/.codex/sessions/2026/07/07/rollout-*.jsonl. The Windows fallback scanned ~/.codex/sessions/2026/07/08/ and never saw it.

Root cause

CodexCollector::map_pid_to_jsonl in src/collector/codex.rs has a #[cfg(target_os = "windows")] arm (Windows has no lsof / /proc/{pid}/fd). It used Self::today_session_dir(sessions_dir) to enumerate candidate rollout-*.jsonl files — i.e. only ~/.codex/sessions/<today>/*.jsonl. A resumed session's rollout file lives under a previous date directory, so it was invisible to the fallback and the PID was left unmapped.

This is the same root cause and fix direction the issue reporter (@Astiyac) identified and locally validated; this PR implements it.

Fix

Scan ~/.codex/sessions/ recursively for rollout-*.jsonl across all dated YYYY/MM/DD/ subdirectories, instead of only today's. The existing strategy is preserved unchanged:

• candidates sorted by modification time descending (most recent first)
• most-recently-modified file assigned to the first discovered Codex PID, and so on
• still Windows-only; the #[cfg(target_os = "linux")] (/proc/{pid}/fd) and macOS (lsof) arms are untouched

Implementation: a new #[cfg(target_os = "windows")] fn collect_all_rollouts_with_mtime recurses the sessions tree collecting (PathBuf, SystemTime) pairs; the Windows arm of map_pid_to_jsonl now calls it instead of today_session_dir + read_dir.

Why this is safe

• Linux/macOS unchanged — the change is fully #[cfg(target_os = "windows")]-gated. The non-Windows arms compile to the same code as before.
• No behavior change for same-day sessions — today's directory is a subset of the recursive scan, and the mtime-sort + PID-assignment logic is identical, so a same-day session is still mapped to its PID exactly as before. The recursive scan only adds visibility into previous-date resumed sessions.
• The recursive-walk pattern already exists in the file (collect_recent_desktop_rollouts), so this mirrors an established approach.

Validation

• cargo clippy --target x86_64-pc-windows-gnu -- -D warnings — clean.
• cargo clippy --target x86_64-pc-windows-msvc -- -D warnings — clean.
• cargo test --target x86_64-pc-windows-gnu --no-run — the test binary compiles and links cleanly (this type-checks the new #[cfg(windows)] function and the #[cfg(windows)] regression test fully; a reference error or signature mismatch would fail to link).
• New Windows-gated regression test windows_map_pid_to_jsonl_finds_resumed_session_under_previous_date_dir (#[cfg(target_os = "windows")]) builds two dated dirs (today + a previous date), writes a rollout in each with the previous-date one more recently modified, and asserts the Windows fallback maps the resumed (previous-date) rollout to the first PID — i.e. the Windows: resumed Codex CLI sessions from previous dates may not be detected #153 scenario now resolves.

Caveat (honest): the repo's CI (ci.yml) runs cargo clippy / cargo test / cargo build --release on ubuntu-latest only, so the Windows branch is not exercised by CI — this is exactly why #153's reporter had to build a Windows abtop.exe to validate. The #[cfg(target_os = "windows")] test is compiled/linked locally against the x86_64-pc-windows-gnu target; a Windows host (or the reporter's CI build) is needed to actually execute it. The change also compiles clean on aarch64-apple-darwin (the non-Windows arms) under -D warnings, confirming Linux/macOS are untouched.