[P2] Crash loops lose their magnitude once `crash` is capped per session

Deferred from the /bmad-code-review on PR #840 (Blind Hunter layer), verified before deferring.

PR #840 capped and deduped the crash event per session, which it had to: one session emitted 8,269 crash events on 2026-09-12 and spent the ingest route's per-IP minute budget doing it, so that session's session_builds, tool_session_uses, session_fps and session_end were 429'd away.

The cost is that occurrence COUNT is now unrecoverable. A two-loss blip and an 8,269-loss catastrophe emit the same two rows: the first loss and the first repeat. repeat: true says a loop happened, but it is a boolean, so it cannot say whether the loop ran twice or ten thousand times. That magnitude is exactly what distinguishes a device that hiccuped from one that is unusable, and it is the signal the #538 work cares about.

Not fixed inline because it needs a new number in the vocabulary, which is a wider change than the defect PR #840 was fixing, and the shape is a real choice:

• A crashes count on a per-session summary emitted at session end, alongside session_builds / session_fps. Fits the existing once-per-session summary family and costs one event. Downside: a session killed outright never reports it, so the worst loops are the likeliest to be missing (the same bias session_emergencies already accepts).
• A suppressed count on the LAST crash event the cap lets through, so the number rides an event that has already proven it can be delivered. Downside: the cap's whole point is that later events are not sent, so "the last one through" is not the last occurrence and the count would be a lower bound taken at the wrong moment.
• Widen SessionThrottle to report its suppressed tally (src/analyticsThrottle.ts already tracks count) and let each caller decide. Cheapest mechanism, still needs one of the two choices above to carry it.

Preferred: the per-session summary, matching session_emergencies, which already accepts the same delivery bias for the same reason.

Related: the $exception mirror has had this limitation since it shipped (it pins one fingerprint for every WebGL loss), so any fix should cover both paths or say why not.

src/analyticsSession.ts noteCrash, src/analyticsThrottle.ts. /bmad-code-review.

Start with src/analyticsSession.ts and noteCrash, then inspect src/analyticsThrottle.ts to understand how the existing count is tracked and capped. Compare the session summary path with session_emergencies and trace the related $exception mirror; done means an agreed count design covers both crash paths without restoring the per-session event flood.