feat: account-wide pooled module overage (migration 030)

[I-am-nothing]

What

Moves module overage from per-app to a single account-wide pool of 5 included modules, per the owner spec 2026-07-05 (confirmed reversal of the base-fee v1 per-app tier).

• One pool of 5 for the whole account — sum module_count across all live apps; $3/month for each module beyond the pooled 5, charged once at the account level.
• The flat $20/app base fee is unchanged and stays per-app. Only the $3/module overage math moved.
• One 3-day grace timer per account.

How

Schema — migration 030 (030 was free in this worktree; 028 was the prior latest):

• accounts.overage_since TIMESTAMPTZ NULL — the one grace-timer anchor.
• account_overage_snapshots — per-(account, period_start) charge ledger; the double-charge guard, mirroring app_base_snapshots.

Pricing (usage/basefee.go): removed the per-app AppBaseFeeMicros overage term; added AccountOverageMicros(pooledCount) + ProratedOverageMicros. Per-app base is now flat.

Timer: RegisterApp / SyncAppModules recompute the pool after every module_count write and arm/clear overage_since (first-cross-wins; idempotent clear; no refund on drop, D1e).

Mid-period grace charge: a new sweep in cmd/billing-cycle charges the pooled overage prorated from grace-end → period-end once the 3-day window elapses — a deliberate mid-period charge (the D1b "no mid-period charges" rule now excludes the overage leg; base-fee behavior is unchanged). Deterministic per-(account, period) Stripe idem keys + the snapshot ledger make it money-safe.

Boundary advance leg (charge.go): each app contributes only its flat base; a separate pooled-overage term bills the closing period once, skipped when the sweep already billed it (source='advance').

Display: GetAccountBillResponse gains AccountOverageMicros (additive — no field removed/renamed; included in TotalMicros), snapshot-first else a live pooled estimate. Per-app displayed base is now flat.

Tests

Pool crossing 5 arms the timer; dropping under clears it; grace holds for exactly 3 days; the mid-period charge fires once and is excluded from the next boundary (no double-charge — the key test); interleaved installs sum to the account pool; uninstall never refunds. make test / go vet / go build ./... all clean.

Follow-up / notes

• Docs: mirrorstack-docs/db/ms_billing/ needs a companion update for the new account_overage_snapshots table + accounts.overage_since column — flagging, not doing it here (someone will consolidate docs across the three related billing PRs).
• Frontend not wired — the AccountOverageMicros wire field is additive so existing consumers are unaffected; the web line is a separate PR.
• Edge case I made a judgment call on: when grace hasn't elapsed by the boundary cutover (or overage started very late in the period), the boundary charges the full pooled overage for the closing period per the spec's literal wording. This slightly tensions with "grace protects for 3 days," but the snapshot + idem-key machinery keeps it money-safe (each period billed exactly once), so I followed the spec as written. In the common daily-cron path the sweep bills each period and the boundary always sees the snapshot and skips.

🤖 Generated with Claude Code

[I-am-nothing]

Superseded by #48 — the overage concept (5 included modules, $3/module beyond) carries forward, but the mechanism is fully replaced: single account-wide timer → one independent 3-day timer per module instance, anchored to that module's own install date with live FIFO re-evaluation. Branch feat/account-wide-module-overage kept on origin.