Aggregate Accounts

Live account-level aggregates over personal (user_) orgs.

Mirrors the portal sweep's definitions so a live tile and last night's rollup describe the same population:

• orgs_with_atoms / atoms_total — accounts holding at least one memory, and the platform total (sweep: atoms > 0 / SUM(atoms)). A Vault secret is not a memory and counts in neither (migration 043), as the sweep's per-org total_atoms leaves it out. These two are read through the storage layer's maintenance route, NOT this handler's pool: atoms is under FORCE RLS (013) plus 027's RESTRICTIVE room policies, and a pooled count with no tenant context answers a silent zero — which is precisely what this endpoint shipped to the console on 2026-08-10. They are NULL, with a reason, whenever that route cannot answer. The default-off ADMIN_ATOMS_AGGREGATES_ENABLED kill switch also returns NULL without calling storage; neither path ever produces a fallback zero.
• orgs_with_active_key — accounts with a live key (active_keys > 0).
• orgs_called_30d — accounts with any read or write inside the window; feedbacks deliberately NOT counted, matching the sweep's reads_30d + writes_30d > 0.
• paying_org_ids — non-free tiers as a list (see block comment: the grant carve-out is the portal's to apply). status is deliberately not filtered — the sweep's per-org read doesn't filter it either, and the two surfaces must not disagree about who counts.

days is bound as a SQL parameter; the only interpolated token is the validated {schema} identifier — same guarantees as aggregate/usage above.