Verify and harden BSD timestamp parsing for Antigravity (.created_at) #26

Context

Follow-up to #23 (macOS support, which closed #2). That PR taught tokenline.sh
to parse timestamps on both GNU and BSD date. This issue tracks a low-severity
robustness gap in the BSD branch only — it does not affect Linux/WSL2.

What was found

epoch_from_iso() parses on BSD with a fixed mask over the first 19 chars:

date -u -j -f "%Y-%m-%dT%H:%M:%S" "${iso:0:19}" +%s

This is correct and guaranteed for Claude Code, whose .timestamp is
ISO-8601 UTC with a T separator (2026-06-29T16:32:32.123Z → the 19-char
prefix is always YYYY-MM-DDTHH:MM:SS).

For Antigravity, the script reads .created_at from PLANNER_RESPONSE
lines (see tokenline.sh, the (.timestamp // .created_at) jq query). That
format is currently unverified. If it diverges from the mask — e.g. a space
separator (2026-06-29 16:32:32) instead of T — the BSD date -f parse fails
and the code falls back to the file mtime.

Severity: low. It degrades gracefully (mtime fallback), never crashes, and
only affects the intersection macOS + Antigravity. The GNU/Linux path is
unaffected because date -d accepts many formats.

What to verify

Capture a real Antigravity .created_at value and confirm its exact shape:
separator (T vs space), fractional seconds, and timezone suffix (Z, an
offset, or none). If it's already T-separated and UTC, no code change is
needed and we just document the sample here.

How to discover the format (step-by-step)

1. Open a real Antigravity CLI session and send at least one message, so a
   PLANNER_RESPONSE line is written to the transcript.
2. Locate the transcript .jsonl (its path contains /antigravity-cli/):

   # Linux / WSL2
   find ~ -path '*antigravity*' -name '*.jsonl' 2>/dev/null
   # macOS: also check ~/Library/Application Support

3. Extract the latest created_at exactly as stored:

   tail -n 200 <transcript.jsonl> \
     | jq -r 'select(.type=="PLANNER_RESPONSE") | .created_at' \
     | tail -1

4. Inspect the string: is it T or space separated? Fractional seconds? Z /
   offset / nothing? Paste the raw sample into this issue.
5. (Optional, to confirm the BSD parse) On macOS:

   SAMPLE='<paste the value>'
   date -u -j -f "%Y-%m-%dT%H:%M:%S" "${SAMPLE:0:19}" +%s

   A non-zero exit (or a separator that isn't T) means the mask needs adjusting.

Possible fixes (pick after confirming the format)

Option A — narrow. Only helps if the divergence is a space separator.
Does not make the parser format-agnostic:

iso="${iso/ /T}"   # replace the first space with T, before the :0:19 slice

Option B — format-agnostic. Strips every non-digit and parses a numeric
mask, so it handles space, T, /, etc. in one shot. Still assumes UTC (which
the script already does, since transcripts are UTC):

local digits="${iso//[^0-9]/}"                 # 20260629163232123...
date -u -j -f "%Y%m%d%H%M%S" "${digits:0:14}" +%s 2>/dev/null

Either fix is BSD-branch-only; the GNU branch stays verbatim. If verification
shows Antigravity already uses T, neither fix is necessary.

Acceptance

• A real Antigravity .created_at sample is documented in this issue.
• On macOS (BSD date), the cache timer for Antigravity sessions uses the
  transcript timestamp (not the mtime fallback), matching Linux behavior —
  or we confirm no change is needed.

Refs #23, #2.