feat(data): record which event type each webhook processed

[paulvanbrenk]

Builds on #707.

What

ProcessedWebhookEvents stored only the provider's event id and a timestamp:

public required string EventId { get; set; }
public DateTimeOffset ProcessedAt { get; set; }

Both webhooks write to that one table — StripeWebhook.cs writes Stripe evt_… ids, StytchWebhook.cs writes Svix msg_… ids — and both formats are opaque. The ledger could say how many events were handled, never which kinds.

Why it matters

That's exactly the gap that let #707's bug hide for months. Four of five Stripe event types were being dropped, and this table recorded nothing that would have revealed it — the rows that existed looked identical to the rows that should have existed.

It's also what makes #707 confirmable in production. The thing to watch for after deploying is invoice.payment_succeeded rows starting to appear, which a bare count can't distinguish from someone signing up.

Details

• EventType is nullable, capped at 128 to match EventId beside it (repo convention is explicit lengths; the first draft generated nvarchar(max) and was redone).
• Migrations for both providers, additive and nullable, safe against the existing prod schema.
• patchnotes-email/prisma/schema.prisma mirrors the same database and is updated to match, or the drift check fails.
• Stytch splits its type across object_type and action; joined here as user.CREATE so the column reads like Stripe's dotted types.
• GET /api/admin/webhook-events returns the field. That endpoint exists to answer "did we process that webhook?", which it couldn't do usefully while every row looked the same. OpenAPI spec and generated client regenerated to match.

Rows written before this column exists stay null and can't be backfilled — the id alone doesn't carry the type, and Stripe only serves full event payloads for the last 30 days. The admin endpoint returns them as null rather than omitting them, and there's a test pinning that.

🤖 Generated with Claude Code