A promotional grant must not block account deletion

[bharathm03]

Every account is currently refused account deletion, with nothing it can do to proceed.

ensureDefaultSubscription hands every new account the pro_yearly plan while checkout is disabled (provider: "promo", promotional: true, status: "active", cancelledAt: null). hasRenewingPaidSubscription then asks only whether the plan slug is free and whether the subscription is pending cancellation — neither of which is true of the grant — so it reports a renewing paid subscription and deleteUserAccount returns blocked_subscription.

The app surfaces that as "Cancel your subscription first" and offers Manage subscription, which opens a pricing page whose cards read "Coming soon". There is no subscription to cancel, so the flow is a dead end. The same function backs the web /account page, so both surfaces are affected.

Fix

Exempt the unpurchased grant, checked before the slug test — the grant rides a paid plan's row, so the slug alone cannot tell it apart from a real purchase. promotional already carries exactly this meaning ("Temporary unpurchased grant… Real purchases must omit this").

Why it went unnoticed

Every existing case in account-delete.test.ts seeds a real purchase (planId: "pro_yearly", customerId: "cust_1"), so nothing exercised the promotional path. The new test goes through provisionProductAccountForUser — the path a real signup takes — and asserts the seeded grant is genuinely promotional and on a paid tier, so it cannot quietly go vacuous if the default plan ever changes.

Testing

bun run typecheck clean.

The test suite has not been run. It needs Postgres, which I had no running instance for. Please run before merging:

bun run --filter antgrid-web test tests/services/account-delete.test.ts

[bharathm03]

CI caught a contradiction worth recording: web/tests/routes/account-page.test.ts pinned the old behaviour deliberately, commenting that the promotional grant is "treated like a real paid plan for deletion purposes (accepted limitation during the promo)".

That framing assumed the limitation was temporary. It wasn't: the grant renews nothing, no checkout sold it, GET /account re-provisions it on every visit (so even a lingering free row is upgraded back), and no surface can cancel it. The block was permanent and applied to every account.

Flipped that test to assert the delete control is offered, and recorded the reasoning where the old expectation lived. The run before this change was 618 pass / 1 fail, the single failure being that test; the new deleteUserAccount case passed alongside it, so the fix itself was already proven by CI.