aggregator(snapshots): SnapshotStore groups by serviceId into plain objects — a __proto__/constructor/toString serviceId crashes byService (blanking all snapshot history) and pollutes Object.prototype during compact

Evidence (verified this run, main df6d9f58)

SnapshotStore validates records with isSnapshotRecord, which checks only that serviceId is a non-empty string (pm-stack/aggregator/src/snapshots.ts:303). Two grouping sites then use that unvalidated id as a key in a plain object literal:

• byService() — snapshots.ts:563-565:

  const grouped: Record<string, SnapshotRecord[]> = {};
  for (const r of await this.readAll()) {
    (grouped[r.serviceId] ??= []).push(r);
  }

• compactInner() per-service report — snapshots.ts:703-711: the same (perService[r.serviceId] ??= { before: 0, after: 0 }) accumulation in three loops.

For a prototype spelling, the ??= read walks the prototype chain and returns an inherited member instead of undefined, so nothing is ever assigned under that key:

• grouped["__proto__"] → Object.prototype (no .push)
• grouped["constructor"] → the Object constructor function (no .push)
• grouped["toString"] → Object.prototype.toString (no .push)

Probe (laptop, real module md5-identical to main)

Probe: ~/git/fleet/probe-2026-10-30-laneA-snapproto/ on the laptop — verbatim snapshots.ts (md5 b5055f8a2576d57e25bba0413f08ca78, matching main df6d9f58) + model.ts, run under bun 1.4.2, one process per case. Store file usage-2026-10.jsonl with a normal claude record plus one record whose serviceId is the test spelling (all other fields valid; isSnapshotRecord(bad) === true in every case):

Why it matters

• One poisoned record blanks ALL snapshot history, persistently. byService()'s only production caller is pm-stack/aggregator/src/sources/live.ts:849: const history = await store.byService().catch(() => ({})); — the throw is swallowed and the whole history section renders empty, for every service, not just the bad one. And because the record passes isSnapshotRecord, store.append(feed.snapshots) (live.ts:~846) happily writes it into the monthly JSONL, so the store stays poisoned on every subsequent read until someone hand-edits the file. The snapshot writers are external jobs (fleet-feed collector, stewardship-cycle, backfill) feeding service ids through the feed — the aggregator's own store philosophy is "one bad line never poisons the store" (snapshots.ts:~550), and this line does exactly that.
• Compaction corrupts its own report and the process. With __proto__, compact's counts are added onto Object.prototype (before/after = NaN) for the rest of the scripts/compact-usage-snapshots.ts process, and the service vanishes from perService while still counting in recordsBefore. With constructor, counts land on the Object function. (The rollup data itself is built with a Map at snapshots.ts:201-205 and is unaffected — only the report and the prototype are hit.)
• The safe pattern already exists in the same file/package: appendLocked groups with new Map (snapshots.ts:~620), compactRecordsToRollups groups with a Map, and quota-current.ts:153 groups by serviceId with a Map. These two sites are the outliers. Related but distinct: design(own-key lookups): a plain object is not a map for untrusted keys — one own-key rule for every dynamic lookup #2792 (read-side own-key lookups; its scope note explicitly leaves write-side instances to be reported/fixed separately, cf. aggregator(cost-explorer): a setup named '__proto__' is silently never saved — save/import assign into a plain object, so the name becomes the store's prototype instead of an entry #2851), aggregator(snapshots): isSnapshotRecord never checks limit/resetsAt — a numeric resetsAt crashes the service history chart, a non-numeric limit NaNs it #2483 (isSnapshotRecord limit/resetsAt — different fields/effect).

Acceptance criteria

• byService() returns an entry for a record whose serviceId is __proto__, constructor, or toString (e.g. via a Map converted at the boundary, or an own-key-safe accumulator), and never throws for a record isSnapshotRecord accepts; normal serviceIds unchanged.
• compact()'s perService report includes prototype-spelled serviceIds with correct before/after counts, and running compact leaves Object.prototype untouched (Object.getOwnPropertyNames(Object.prototype) unchanged, ({}).before === undefined).
• Regression tests in the aggregator suite (e.g. pm-stack/aggregator/test/snapshot-retention.test.ts or a snapshots test) covering __proto__/constructor/toString serviceIds for both byService() and compact(), plus the unchanged normal control.
• Triage decides whether isSnapshotRecord should additionally reject prototype spellings as serviceIds — but the grouping fix must not depend on that, since existing store files may already hold such a line.

Found by new-issue-creator-code-a (lane A) this run; probe and this evidence retained at the laptop path above.