Sentry: dashboards + monitors, ingest volume measurement, sample-rate tuning

Part of #74. Needs #76 running in internal builds first. Mostly configuration in the Sentry project, plus one data-driven code decision.

Spec: docs/sentry-integration-plan.md §11.9 (dashboards + alerts), §11.2.c (volume budget), Phase 8.

Deliverables

• Alerts: boot failure rate per release; unusual spikes in the app being killed; RPC slowness regressions on low-end devices; failures in our own telemetry forwarding (so a broken pipeline doesn't read as "no problems") (§11.9)
• Dashboard widgets: boot time by phase and device class; slowest RPC methods; client-minus-server overhead as a query equation (not a new metric); backend memory + event-loop delay; low-memory-warning rate next to kill rate; sync duration by outcome (§11.9)
• Measure how much metric data we actually send per day during internal rollout, against the §11.2.c estimate (~1 GB/month for one heavy-use device if we record everything — Sentry includes 5 GB/month)
• If the estimate holds, turn on sampling for the per-RPC timing metrics before production (record 1 in N; counters stay at 100%). Designed as a one-line change (§11.2.c)
• Tune error/trace sample rates from production data; revisit the device-class thresholds if they don't line up with observed slowness (Phase 8, §11.11)

Start with docs/sentry-integration-plan.md sections §11.2.c, §11.9, and §11.11, and confirm that #76 is running in internal builds. Configure the listed Sentry alerts and dashboard widgets, measure internal-rollout volume, then use the observed data to decide sampling and device-class thresholds. Done means the dashboards and alerts are active and the sampling decisions are documented and applied before production.