Break beacons down by ingestion facts

Response with orthogonal beacon-count breakdowns across the ingestion-side dimensions of the same row set.

Every count here is a count of STORED beacons, never scaled by the sampling weight: the values double as row filters for the beacon explorer, so they have to match the rows that tool can actually show.

The first three maps are fixed-enum and each sums to beacon_count; beacons_by_tracker_version is open-valued and capped at the top-20:

• beacons_by_collection_mode: privacy class. Inferred from session_id: non-empty means the beacon was collected in full mode (consent given or site set to FULL), empty means anonymous.
• beacons_by_delivery_method: transport channel. Server-classified at ingest from request shape + tracker marker (see migration 024).
• beacons_by_lifecycle: pageview-lifecycle stage when the beacon was emitted (init / loaded / hidden / ...). Useful to gauge how often pageviews reach the loaded state vs. bounce before LCP.
• beacons_by_tracker_version: top tracker bundles by beacon volume, format YYMMDD-<git-sha>[-dirty]. Open value space (one per build), so capped at the top-20 by count to bound response size. Lets you watch cache-rollover progress and spot stale builds. Empty string covers legacy beacons (pre-stamp migration) and the static <noscript> pixel which has no runtime to stamp.

Maps over flat *_count fields so new values (additional delivery channels, future lifecycle stages, new tracker builds) flow through without a schema change on either side. Frontend computes percentages from count / beacon_count.