pm-stack(aggregator): recordsFromProviderUsage accepts impossible/non-ISO generated_at — Date.parse-only gate yields records isSnapshotRecord refuses, so the append CLI silently drops the whole provider-usage snapshot #5140

Problem

recordsFromProviderUsage (pm-stack/aggregator/src/snapshot-records.ts:274) gates the provider-usage snapshot's generated_at with a NaN-only Date.parse check at :282:

if (!ts || Number.isNaN(Date.parse(ts))) return [];

Date.parse rolls impossible calendar dates (2026-02-30 → Mar 2, 2026-04-31 → May 1) and accepts non-ISO strings ("March 2, 2026"), so such a stamp passes this gate and is copied verbatim onto every derived record — the sessions count and both Codex windows.

Why it matters

The store's own validator refuses exactly these stamps: isSnapshotRecord (pm-stack/aggregator/src/snapshots.ts:330) requires isIsoDate(r.ts) — "Real calendar dates only (#2264/#2483)". The only live caller, scripts/append-usage-snapshots.ts:88 (--from-provider-usage mode), silently filters derived records through isSnapshotRecord. Net effect: one impossible or non-ISO generated_at silently discards the entire provider-usage snapshot (sessions observation + Codex pct history) with no legible reason — the run just reports fewer/no records appended. The derivation boundary is the right place to refuse, legibly, exactly as this file's sibling derivations already produce only real-calendar stamps (snapshot-records.ts already imports parseIsoDate from validate.ts).

Evidence (verified this run, origin/main d94b895, laptop bun probe)

Snapshot: sessions: [1,2], Codex primary window used_percent: 12, limit_window_seconds: 604800.

• generated_at: "2026-02-30T10:59:33Z" → 2 records returned, ts verbatim; isSnapshotRecord = [false, false]
• generated_at: "2026-04-31T10:59:33Z" → 2 records returned, ts verbatim; isSnapshotRecord = [false, false]
• generated_at: "March 2, 2026" → 2 records returned, ts verbatim; isSnapshotRecord = [false, false]
• generated_at: "not-a-date" → 0 records (control — the current gate catches only this)
• generated_at: "2026-10-26T10:59:33Z" → 2 records; isSnapshotRecord = [true, true] (control)

Dedup: no open or closed issue covers this function/field — #3460/#2568 (closed) are the used_percent range in the same function; #3379 (closed) is the sibling recordsFromDeepseekBalance date-shadow bug, a different function.

Acceptance criteria

• recordsFromProviderUsage returns [] for generated_at values "2026-02-30T10:59:33Z", "2026-04-31T10:59:33Z", and "March 2, 2026" (gate with isIsoDate/parseIsoDate from validate.ts, the same strict primitive isSnapshotRecord uses).
• Valid control unchanged: "2026-10-26T10:59:33Z" still yields the sessions record plus the Codex window records, all passing isSnapshotRecord.
• Garbage ("not-a-date") and missing generated_at still yield [].
• New tests in pm-stack/aggregator/test/snapshot-writers.test.ts cover the impossible/non-ISO refusals and the valid control; bun test in pm-stack/aggregator passes.