feat(payments): Phase 0b — create-stripe-subscription + fix webhook template_user_id (closes #102)

[TortoiseWolfe]

Summary

Second sub-issue of the Phase 0 epic (#100). Ships create-stripe-subscription AND fixes a paired bug in the existing stripe-webhook that would prevent subscription rows from being inserted.

Closes #102.

Why a webhook fix lives in the same PR

The subscriptions table requires template_user_id NOT NULL. The existing handleSubscriptionEvent in stripe-webhook never set it — the bug was latent because no production flow lit up the subscription path. Phase 0b activates that path, so the webhook fix is required to keep it working.

What ships

Path	What
supabase/functions/create-stripe-subscription/	POST {price_id, customer_email} → creates Stripe Checkout Session in subscription mode → returns {sessionId}. Sets subscription_data.metadata.template_user_id so the webhook can satisfy the NOT NULL constraint.
supabase/functions/stripe-webhook/index.ts	handleSubscriptionEvent now reads template_user_id + customer_email from subscription.metadata and writes both on the upsert. Returns {handled:false} (with logged error) when metadata is absent.
docs/PAYMENT-DEPLOYMENT.md	Status table updated → Phase 0a + 0b shipped. Step 4.2 lists the three deployable functions. Operator note clarifies stripe-webhook must be re-deployed after this PR lands.

Why no subscriptions row is inserted at session-creation time

At session-creation we don't have provider_subscription_id — Stripe assigns it post-checkout when the customer completes payment. The table's provider_subscription_id is NOT NULL UNIQUE. The clean handoff:

create-stripe-subscription:
  → Creates Stripe Checkout Session (with metadata)
  → Returns sessionId
  → Browser redirects user to Stripe-hosted checkout

Customer completes checkout → Stripe fires:
  → customer.subscription.created (with metadata propagated from session)
  → stripe-webhook upserts subscriptions row with status='active'

Security model

Identical to Phase 0a:

• JWT verified via NEXT_PUBLIC_SUPABASE_ANON_KEY
• Caller's user_id flows into Stripe metadata so the webhook can attribute the subscription row to the right user
• Email validation matches payment-service.ts regex

Operator deploy steps post-merge

supabase functions deploy create-stripe-subscription
supabase functions deploy stripe-webhook  # re-deploy due to handler fix

Then SubscriptionManager subscribe flow works end-to-end against Stripe sandbox.

What this PR does NOT do

• ❌ Phase 0c (PayPal one-off) — [Phase 0c] PayPal one-off: create-paypal-order + capture-paypal-order (~4h) #103
• ❌ Phase 0d (PayPal subscription) — [Phase 0d] PayPal subscription: create-paypal-subscription (~2h) #104
• ❌ Phase 0e (cancel + resume subscription) — [Phase 0e] Subscription lifecycle: cancel-subscription + resume-subscription (~3h) #105
• ❌ Un-skip E2E payment tests — [Phase 0f] Shared infra + un-skip 86 E2E payment tests (~2h) #106
• ❌ Schema changes (table is already correct, the bug was webhook-side)
• ❌ Browser code changes (the createSubscriptionCheckout caller already
  passes price_id + customer_email per the contract this function
  implements; Authorization header was added in Phase 0a's feat(payments): Phase 0a — create-stripe-checkout + verify-stripe-session (closes #101) #110)

Test plan

• 81/81 payment unit tests pass
• 302/302 test files, 3329 unit tests pass
• Type-check clean
• Lint clean
• No regression in Phase 0a functions
• CI green on this PR
• E2E subscription flow validated post-merge when sandbox keys land (un-skipped in [Phase 0f] Shared infra + un-skip 86 E2E payment tests (~2h) #106)

🤖 Generated with Claude Code