Reworked the plan and spec and schema PR against current Worldpay.

The main changes:

• No Subscription API database changes. Removed all three subscription columns, the effects table, and the delivery table.
• Worldpay’s familiar model: account info → billing attempts → successful transactions/refunds, using the same queue, worker, HTTP-route and deployment patterns.
• One source for subscription state. No duplicated schedule, autorenewal setting or cross-service revision protocol.
• Rare cases go to manual review. Removed the elaborate lifecycle and notification-recovery machinery.
• Customer behavior stays intact: amounts, calendar dates, retry behavior and access during pending payments.

I departed from John’s prompt where literal parity would change billing behavior or leave a correctness gap. The remaining additions are explicit: pending-payment reconciliation, persisted refund intent, and a small conditional check on the existing subscription-update API to protect cancellation/extensions. That check requires no new database columns.

The build plan is now 10 phases instead of 18.

The revised schema passed 151 hosted PostgreSQL assertions, including apply → rollback → reapply. Formatting and document consistency checks passed. Broader CI and reviews remain pending; nothing was merged or deployed.