feat(payments): Phase 0a — create-stripe-checkout + verify-stripe-session (closes #101)

[TortoiseWolfe]

Summary

First of 6 sub-issues of the Phase 0 epic (#100). Ships the 2 outbound Edge Functions for Stripe one-off checkout + the shared CORS / auth helpers that all subsequent Phase 0 PRs will reuse.

With this PR, /payment-demo Stripe tab actually charges a card end-to-end once sandbox keys are configured. Before: clicking Pay hit a 404 against a nonexistent function URL.

Closes #101.

What ships

Path	What
supabase/functions/_shared/cors.ts	Allowed-origin echo + JSON response builder. No wildcards (these functions move money).
supabase/functions/_shared/auth.ts	Extracts user_id from Authorization: Bearer <jwt>. Throws UnauthorizedError on absent/malformed/invalid.
supabase/functions/create-stripe-checkout/	POST {payment_intent_id} → creates Stripe Checkout Session with metadata.intent_id for webhook correlation → returns {sessionId}. Owner-check enforced.
supabase/functions/verify-stripe-session/	POST {session_id} → wraps stripe.checkout.sessions.retrieve → returns {payment_status}. Owner-check via session's payment_intent.metadata.intent_id.
src/lib/payments/stripe.ts	Adds Authorization: Bearer <jwt> to all 3 fetch sites via a getAuthHeader() helper.
vitest.config.ts	Excludes supabase/functions/** from Vitest discovery (Deno test files use https:// imports that the Node ESM loader rejects).
docs/PAYMENT-DEPLOYMENT.md	Status table → "Partially shipped". Step 4.2 lists the 2 deployable functions.

Security model

• JWT verified via NEXT_PUBLIC_SUPABASE_ANON_KEY in the Edge Function
• Service-role client used only AFTER ownership is verified (payment_intents.template_user_id === caller.user_id)
• Stripe metadata.intent_id is the correlation key that stripe-webhook (already shipped at stripe-webhook/index.ts:171) reads to map provider events back to our DB rows
• Expiry check matches isPaymentIntentExpired in payment-service.ts
• Type check: this function rejects type='recurring' intents (those go through Phase 0b's create-stripe-subscription)

What this PR does NOT do

• ❌ Phase 0b (create-stripe-subscription) — tracked in [Phase 0b] Stripe subscription: create-stripe-subscription (~3h) #102
• ❌ Phase 0c (create-paypal-order + capture-paypal-order) — [Phase 0c] PayPal one-off: create-paypal-order + capture-paypal-order (~4h) #103
• ❌ Phase 0d (create-paypal-subscription) — [Phase 0d] PayPal subscription: create-paypal-subscription (~2h) #104
• ❌ Phase 0e (cancel-subscription + 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 (batch un-skip after all 8 functions ship)
• ❌ Seed deterministic conversation data — [Round 14b] Seed deterministic conversation data for messaging-scroll spec (~2h, follow-up) #109 (low-priority follow-up)
• ❌ Touch any payment_intents/payment_results/subscriptions schema (no migration needed; the existing payment_results.transaction_id is the linkage)

Test plan

• 302 test files, 3329 unit tests pass
• Type-check clean (strict mode)
• Lint clean
• No regression in 81 existing payment unit tests
• Browser-side fetch sites still type-check after Authorization header addition
• CI green on this PR
• After merge + sandbox keys deployed: supabase functions deploy create-stripe-checkout verify-stripe-session works
• /payment-demo Stripe tab completes a test-card checkout end-to-end (validated as part of [Phase 0f] Shared infra + un-skip 86 E2E payment tests (~2h) #106 once all 8 functions ship and tests un-skip)

Operator note (post-merge)

After this lands and the operator follows docs/PAYMENT-DEPLOYMENT.md Steps 1-3 (project link, migration, env vars), they can:

supabase functions deploy create-stripe-checkout
supabase functions deploy verify-stripe-session

And the Stripe tab on /payment-demo will work end-to-end. PayPal tab still 404s until Phase 0c.

🤖 Generated with Claude Code