aggregator: SnapshotStore accepts records it can never read back — non-finite estimate pairs and non-ISO timestamps pass validation, append reports success, and dedupe never sees them

Summary

isSnapshotRecord (pm-stack/aggregator/src/snapshots.ts:26-42) is the shared
structural validator for the usage snapshot store: the store's own
readAll/append, the feed ingest in sources/live.ts (which appends
feed.snapshots into the local store), and the writer scripts
(collect-fleet-feed.ts, gather-quota.ts, append-usage-snapshots.ts) all
gate on it. Two classes of record pass that validator but can never be read
back by the store, so SnapshotStore.append reports them as written, they
never appear in history, and — because dedupe is computed from readAll —
re-appending the same record appends it again every time.

Evidence (verified on main 3b55904, Bun 1.4.2, verbatim snapshots.ts sha256 49b14289 on the laptop)

Probe: probe-2026-10-27-laneB-snapshots (real snapshots.ts, only the
type-only model.ts import stubbed).

1. Estimate pairs skip the finiteness check scalars get. Scalar
   value: NaN → isSnapshotRecord false (line 34: Number.isFinite), but
   value: { low: NaN, high: 10 } → true, and { low: Infinity, high: 10 }
   → true (lines 35-38 check only typeof === "number"). An inverted
   pair { low: 50, high: 10 } also passes.
   • append([NaN-pair]) returns 1; the stored line has
     "value":{"low":null,"high":10} (JSON.stringify turns NaN into null),
     which readAll then rejects — readAll() returns 0 records.
   • append([same NaN-pair]) again returns 1 (not 0): dedupe is built
     from readAll (snapshots.ts:99), which never sees the stored line, so
     every re-run of a writer appends another dead line and reports it as a
     new observation. The monthly file grows with records no reader will
     ever return.
2. Any Date.parse-able ts passes, but file routing assumes an ISO
   prefix. snapshotFileFor (snapshots.ts:20-22) routes by
   ts.slice(0, 7), and readAll only reads files matching
   usage-(\d{4}-\d{2})\.jsonl (line 17). A record with
   ts: "October 20, 2026" passes isSnapshotRecord (line 29 only requires
   Date.parse to succeed), append returns 1 and writes it to
   usage-October.jsonl — a file readAll filters out, so readAll()
   returns 0. Same silent-loss + no-dedupe shape as (1).
3. Control: a normal ISO record with a finite pair appends once, the
   second append returns 0 (dedupe works), and readAll returns 1.

Why it matters

The snapshot store is the append-only usage history the hub's history views
are built from, and its contract (module header, snapshots.ts:1-10) is that
writers and the backfill are "safe to re-run" because dedupe makes appends
idempotent. Records in either class above break that contract silently:
append counts them as stored history, no surface ever shows them, and every
writer re-run adds another copy. The pair case is reachable from any writer
whose estimate arithmetic can produce NaN/Infinity (e.g. a division by a
zero denominator upstream) — the validator is exactly the boundary that is
supposed to keep such values out, and it already does so for scalar values.

Acceptance criteria

• isSnapshotRecord rejects estimate pairs whose low or high is not a
  finite number (mirroring the scalar branch), and rejects a pair with
  low > high.
• isSnapshotRecord rejects a ts whose first 7 characters are not a
  YYYY-MM month the store can route (or, equivalently, snapshotFileFor
  output is guaranteed to match the readAll file pattern for every
  accepted record).
• Regression tests: appending a NaN/Infinity-pair record and a non-ISO-ts
  record each append 0 and write nothing; the existing finite-pair control
  still appends once and dedupes on re-append.
• No change to the on-disk format or to the dedupe key for valid records.

Notes

• Deliberately not self-solved by the creator lane: the low > high ruling
  and the exact ts shape to require (full ISO vs YYYY-MM prefix) are small
  contract decisions for triage, and this validator is shared by four
  writer/reader paths.
• Related, different defect: aggregator: concurrent writes to the JSON stores share one temp path — most fail with ENOENT (returned as '400 invalid'), and persisted records don't match the calls that succeeded #1509 (concurrent JSON-store writes in the
  aggregator) — same app, unrelated module and mechanism.