## Summary

`omarchy-agent-usage-grok` (`local_stats`) and `omarchy-agent-usage-codex`
(`local_day`, called from `scan_pi_sessions`) don't wrap per-file/per-entry
parsing in error handling. A single malformed session file raises an
uncaught exception, which aborts the whole collector run for that agent.
No JSON record is printed, so the agents panel loses that agent's usage
row, limits, and history entirely until the bad file is fixed by hand —
with no error shown to the user.

For comparison, `omarchy-agent-usage-claude` wraps every session/turn in
`try/except: continue`, so a bad file there only costs one session, not
the whole record. That's the pattern the other two collectors are missing.

## Reproduction (executed against current `quattro`, 2026-10-06)

Loading the collector modules directly and feeding them the values below
reproduces every case:

| Collector | Input | Result |
|---|---|---|
| grok `local_stats` | `summary.json` `num_messages: "3.0"` | `ValueError: invalid literal for int() ... '3.0'` |
| grok `local_stats` | `summary.json` `last_active_at: "0001-01-01T00:00:00+00:00"` | `OverflowError: date value out of range` in `.astimezone()` |
| grok `local_stats` | `usage.json` `inputTokens: "12.5"` | `ValueError: invalid literal ... '12.5'` |
| codex `local_day` | numeric timestamp `1.7e18` (nanosecond-style) | `ValueError: year 53872825 is out of range` |
| codex `local_day` | `1e20` / `1e300` | `OSError` / `OverflowError: timestamp out of range` |

`1.7e18` is a realistic value, not a contrived one: nanosecond epochs are a
common convention, the value passes the `> 10_000_000_000` milliseconds
heuristic in `local_day`, and still overflows after the `/1000` normalization.

## Where this stands after commit 75250d3

That commit ("Fix Codex limits, Claude counting, and agent usage reliability
from community PRs", 2026-10-03) already added per-file `try/except` around
two of `omarchy-agent-usage-codex`'s three `local_day` call sites:

- `scan_native_codex_sessions` → `read_native_codex_session`: now wrapped,
  degrades to one file instead of crashing. Fixed.
- `scan_opencode_sessions`: likewise now wrapped. Fixed.
- `scan_pi_sessions` (the call at `local_day(entry.get("timestamp") or
  message.get("timestamp"))`): still unwrapped, and `run_local_scans` calls
  it with no guard of its own. A poisoned timestamp reaching this path still
  aborts the whole scan *before* the other two (now-fixed) scans even run —
  so this path is actually the more serious of the two: it can take out the
  native-codex and opencode results too, not just its own agent's row.
  `cached_local_stats`'s `try/except` only catches cache-layer failures and
  retries by calling `run_local_scans` directly; a data-parsing error fires
  again on that retry, unguarded, and `main()` has no top-level try either.
- `omarchy-agent-usage-grok` wasn't touched by that commit — `local_stats`
  and its only caller chain (`cached_local_stats` → `main`) still have zero
  error handling anywhere.

## Suggested fix

Mirror the Claude collector's pattern in the two remaining spots: wrap the
per-session body of grok's `local_stats` loop, and the `scan_pi_sessions`
call to `local_day`, in the same per-item `try/except: continue` already
used elsewhere in the codex file. A malformed file should cost one
session's data, not the agent's whole record.

## Impact

No security boundary is crossed — this is an availability/correctness bug,
not a vulnerability. A single bad session file (partially written because a
tool crashed mid-write, a newer schema field with a float where an int is
expected, or a nanosecond-epoch timestamp) is enough to silently drop an
agent's entire usage display with no error surfaced to the user.