Pro entitlement not applied after successful checkout; Google sign-in then fails with identity_already_exists

Summary

After completing a paid Pro (yearly) checkout, the account stays on the Community plan. Linking Google afterwards leaves the entitlement stranded, and signing in with that same Google account on the other domain fails with identity_already_exists.

Steps to reproduce

1. Open /pricing while signed out.
2. Complete Pro yearly checkout via Stripe/Link. The redirect returns to /pricing?checkout=success on threeui.netlify.app, followed by a /pricing/#access_token=... callback.
3. Connect Google afterwards, as the pricing FAQ instructs: "After payment, connect Google so you can recover your Pro access on another device."
4. Reload /pricing and open the account menu.

Expected

The account shows the Pro plan, and Pro components unlock.

Actual

• The account menu still shows Community plan long after payment. Reloading does not change it.
• The Stripe subscription is active and a receipt was issued, so the charge itself succeeded.
• Signing in with the same Google account on threeui.com redirects to:

https://threeui.com/pricing?error=server_error&error_code=identity_already_exists&error_description=Identity+is+already+linked+to+another+user

Suspected cause

Checkout appears to create an anonymous Supabase user, and the post-payment Google link attaches the Google identity to that anonymous record. A later OAuth sign-in on the other domain resolves to a different user and then cannot claim the already-linked identity, so the entitlement sits on an account the buyer can never sign into.

This looks related to #4, which flagged the same threeui.com vs threeui.netlify.app Supabase Site URL and allowed-origin mismatch.

Environment

• Domains: threeui.netlify.app and threeui.com
• Auth: Supabase Google OAuth
• Desktop Chrome on macOS

Impact

A paying customer is left on the Community plan with no self-serve way to recover access. It also encourages repeat checkout attempts, which risks duplicate charges.

Suggested fix

• Attach the Stripe entitlement to the email on the Checkout session rather than to the anonymous session's user id.
• When identity_already_exists comes back, sign the user into the existing identity's account instead of returning a server error.
• Align the Supabase Site URL and redirect allow-list across both domains (see #4).

Start at the /pricing checkout-success and access-token callback, then trace the Supabase Google OAuth flow and Stripe checkout session across threeui.netlify.app and threeui.com. Compare the Site URL and redirect allow-list noted in issue #4. Done means a paid account shows Pro, Pro components unlock, and the linked Google identity can sign in on the other domain without identity_already_exists.