Allow users to self-delete their accounts in multiuser mode

[philipithomas]

Summary

Adds account self-deletion to the page settings in multiuser mode, with type-to-confirm friction, synchronous billing cancellation, and asynchronous full data cleanup.

User flow

• Settings page danger zone (pages/edit): a "Delete account" section shown only in multiuser mode and only to the account owner (not to admins viewing another account's settings).
• Confirmation modal (new delete-account Stimulus controller): the user must type their postcard address (e.g. username.postcard.page) before the delete button enables. Closes on Escape or backdrop click. The confirmation is re-verified server-side (case/whitespace-insensitive).

Billing cancellation (synchronous, fail-loud)

Pay's cancel-on-destroy callback is unsafe for this: it swallows API errors (logs and continues, so a failed Stripe call would delete local records while the subscription keeps billing) and its active? check skips past_due subscriptions (a customer in dunning would keep getting retried after deletion). Instead, AccountController#destroy deletes the Stripe customer itself — Stripe immediately cancels all of a deleted customer's subscriptions regardless of status, and scrubs their details from Stripe. If the API call fails, deletion aborts with a contact-support message.

Deletion (asynchronous)

Established accounts can have hundreds of thousands of analytics, subscriber, and email rows; the previous cascade destroyed them row by row (visits → events individually instantiated, audited subscriber destroys) — far too slow for a request. Now:

1. The controller locks the account (lock_access!) — sign-in is blocked and the public page 403s immediately — signs the user out, and enqueues DestroyAccountJob.
2. The job bulk-deletes in batches: the account's visits/events, visitor page-view events (matched via the GIN jsonb_path_ops index on ahoy_events.properties — these were previously orphaned), email messages, and subscriber records; destroys Pay::Customer records (Pay never cleans these up on owner destroy); runs account.destroy! for the rest (posts, domains, imports, attachments) with normal callbacks; and finally purges audit snapshots, which contain account PII.

Also

• Closed a bypass: Devise's default DELETE /accounts destroy (no typed confirmation, no billing cleanup) now redirects to this flow in multiuser mode; solo mode unchanged.
• Reworded the cancel-account copy to "Done with Postcard?".

Tests

test/controllers/account_controller_test.rb (8 tests): lock + enqueue + sign-out on success, full data cascade when the job runs, case/whitespace-insensitive confirmation, wrong-confirmation rejection, solo-mode block, other-account block, auth requirement, Devise destroy redirect. test/jobs/destroy_account_job_test.rb: bulk deletion of visits, own and visitor analytics events, subscribers, email messages, and audits, while shared EmailAddress records survive.

rails test, rails zeitwerk:check, and brakeman all pass.

🤖 Generated with Claude Code