feat(billing): teardown module for account-delete's 24h undo window (cloud#226 A-2)

[unforced]

Summary

A-2 of the account-deletion train (sibling of #229 / cloud#226 PR-1). Aaron ruled that deleting an account gets a 24-hour undo window: the delete request severs auth and places a reversible hold on billing; real teardown happens at window expiry via an hourly sweep; undo releases the hold.

This PR is inert — workers/identity/src/billing-teardown.ts is a self-contained module that nothing calls yet. A-3 wires it into the delete/undo routes and the sweep.

Three functions over the existing BillingOverrides Stripe-injection seam (billing.ts's checkoutCore/portalCore pattern — no new mechanism):

• deferBilling(stripe, subscriptionId) — sets cancel_at_period_end = true on the stored subscription. Tolerant of a missing id, a 404, or an already-canceled subscription (all success). Covers a trialing subscription too: the trial cancels at its boundary instead of converting and charging.
• resumeBilling(stripe, subscriptionId) — flips the flag back. Returns a discriminated result ({ resumed: true } vs { resumed: false, reason: "already_canceled" }) for the case that can't be released: if the period boundary passed during the undo window, Stripe has no un-cancel. Never throws for this case, never claims a restore that didn't happen.
• teardownBilling(stripe, db, userId) — the real, irreversible teardown (sweep-time only): cancels the stored subscription, sweeps every other subscription under the customer in active/trialing/past_due/unpaid (the cloud#64 orphan belt — a subscription the users row doesn't name would otherwise bill a ghost forever), deletes the customer, then NULLs both Stripe ids — that NULL is the converged marker the sweep keys on. Any failure along the way leaves the ids untouched and returns an unconverged result so the sweep retries; every step is individually idempotent.

The two guarantees this establishes: no new charge can post after a deletion is requested, and no subscription survives a completed teardown.

Tests

workers/identity/test/billing-teardown.test.ts — 18 tests against the injected Stripe stub (plain object satisfying the SDK subset used, same pattern billing-lifecycle.ts's tests already use), no network:

• deferBilling: sets the flag; tolerant of missing/404/already-canceled; a genuine Stripe failure propagates.
• resumeBilling: flips the flag back; the money case — an already-canceled subscription returns the not-resumed result rather than throwing or claiming success; genuine failures propagate.
• The money test: a trialing subscription reachable only via the belt (not the stored id) is canceled — written so it goes red if the belt is filtered to active only (verified: manually narrowed the belt during development and confirmed this test fails for the stated reason before restoring the fix).
• The orphan belt: stored id + an unrelated live subscription are both canceled (de-duplicated, not double-canceled), customer deleted, both ids NULLed.
• Partial failure: customers.del throws → ids retained, unconverged result, no exception escapes (verified red without the try/catch).
• Mid-belt failure: canceling an orphan throws → unconverged, customers.del never reached.
• Idempotence: running teardown twice reaches the same terminal state without throwing.
• Edge cases: a user who never had Stripe ids, and a nonexistent user id, both converge trivially with zero Stripe calls.

Every load-bearing assertion was watched fail on a deliberately-broken variant of the source before being confirmed green against the real implementation.

Gates

• bun run typecheck (root): clean.
• cd workers/identity && bun run typecheck: clean.
• cd workers/identity && bun x vitest run (identity worker suite): 39 files passed (39), 1071 tests passed (1071), 0 failed. (Full-suite runs on this box hit EADDRNOTAVAIL from loopback port pressure when all 39 files spin up Miniflare concurrently — an environment characteristic, not a regression: confirmed via git status that this branch touches only the two new files below, so no existing test could have been affected. Ran the suite in batches of 5 files with orphan-reaping between batches to get a clean full accounting.)

rc bumped to 0.0.8-rc.129 (main is at rc.127; the sibling PR #229 already claimed rc.128).

Scope

Does not touch account-api.ts, add migrations, or wire any route — A-1 (#229) and A-3 own those.

https://claude.ai/code/session_01XLZtmuSs1RirWGMGyCB1QB