6r. A control-plane database filling up

The control plane has two databases: its own (divvent-<env>: sign-in, billing, audit, deploys) and the telemetry store (divvent-<env>-telemetry-store: the tenants' pushed numbers, browser faults, rate-limit allowances). The hourly pass reads both sizes (watchDatabases) and mails the operator address once when either passes 50%, 80% or 90% of D1's 10 GB; the console's home page names it until it falls back.

• The telemetry store is the one expected to grow. It keeps thirty days (TELEMETRY_RETENTION_DAYS); check the scheduler's telemetry-sweep: … left line — a number that grows every hour is a sweep being outrun. Lowering the retention is a code change; the caps per target are in telemetry-store.ts. At the limit D1 refuses writes: tenants' batches are refused (their apps are unaffected — telemetry is fire-and-forget), and nothing else stops.
• The control plane's database past 50% is not expected: find which table grew (wrangler d1 execute divvent-<env> --remote --command "SELECT name, COUNT(*) …" per table). The audit log is never swept, by design; the drain's platform_fault is swept at thirty days by the same hourly pass.
• After the store is first deployed, the hourly databases: line says how many telemetry rows it moved from the control plane's database and how many are left. When it says 0 left on two passes running, the control plane's old telemetry tables are empty and a later migration may drop them.