Make the purchase real, through RevenueCat

[maximsan]

The code is written and on #602. This stays open because nothing here has met a real store: the acceptance below cannot be run until the account work is done.

ADR-0024 rules how this lands — the build ships able to sell all three arms, and which arms are live is a RevenueCat setting from then on. RevenueCat assigns the arm, holds the entitlement and reports the revenue; the app keeps its own paywall screens.

Owner's part — what is blocking

Account tasks nobody else can do. The step list is in docs/10-payments.md under Going live checklist.

• RevenueCat account, linked to App Store Connect with an API key
• Register the non-consumable and a subscription group holding the monthly and the yearly; price all three. One submission — Apple takes the first in-app purchase of each type only alongside an app version
• One RevenueCat offering per arm, named one_time, subscription, hybrid
• Enable the In-App Purchase capability in Xcode → Runner → Signing & Capabilities
• A sandbox tester account

Done in #602

RevenueCatPaymentsService behind the existing seam; entitlement that can expire, so a lapsed subscription locks the course with no restart; Settings → Purchases as a real screen, with the arm's offer, Restore, and a link out to Apple for a renewing plan. Which plan an owner holds is asked of the store, so it survives a restart or a change made outside the app. InAppPurchaseService is deleted.

The paywall's prices needed no work: paywallViewProvider already fetches products and paywall_view.dart already substitutes {price} and {perMonth}. They render blank today only because the no-op store returns no products.

Acceptance

• A sandbox purchase on each of the three arms unlocks Foundations, and it survives an app restart
• Restore Purchases recovers it on a fresh install with the same Apple Account
• A lapsed subscription locks Foundations again without an app restart
• Cancelling or failing a purchase leaves the learner unchanged, with no gate flicker

[ClaytonPetrosian]

The remaining work is nicely bounded: one non-consumable, a real product lookup, purchase, restore, and one entitlement provider that the existing surfaces already consume. I recently shipped a production StoreKit purchase path in an Expo app and can take a fixed-scope paid review/patch for this ticket: trace the Flutter in_app_purchase flow, keep the provider boundary intact, source the localized price from the store product, cover cancel/failure/restore/restart states, and return a patch plus a short verification report. I would leave App Store Connect registration and sandbox-account steps with the owner as described here. The current billing review scope is US$49: https://marketing-eight-steel.vercel.app/billing-review

If useful, reply with the public branch and I can confirm the exact scope before payment. The acceptance checklist here is already a strong handoff for whoever implements it.