feat(db): add widget_events table for lifecycle instrumentation

[nawneet77]

Summary

Adds a raw event-stream table for embedded feedback widgets so widget lifecycle signals (init, identify, launcher_show, open, close) can be captured at write-time and later rolled up by an aggregator job.

This is the foundational data-layer slice. No app-layer wiring is included in this PR — that comes next.

Why this and not analytics_daily_stats

analytics_daily_stats already tracks downstream activity (new posts / votes / comments, including postsBySource.widget). It doesn't see the upstream impression and engagement signals — how often the launcher renders, how often it opens, how many open sessions never result in a post. Those need a separate raw stream that an aggregator can summarize, which is what this table provides.

Schema

widget_events (
  id            uuid PRIMARY KEY
  event_type    text NOT NULL          -- 'init' | 'identify' | 'launcher_show' | 'open' | 'close'
  platform      text NOT NULL          -- 'web' | 'ios' | 'rn' | 'android'
  session_id    text                   -- correlates events from the same widget instance
  principal_id  uuid                   -- set when identify() was called with a verified SSO token; null otherwise
  user_agent    text                   -- UA for web; device model + OS for native
  metadata      jsonb NOT NULL DEFAULT '{}'
  created_at    timestamptz NOT NULL DEFAULT now()
)

Indexes:

• created_at DESC — time-window scans
• (event_type, created_at DESC) — "opens in the last 24h" style queries
• (principal_id, created_at DESC) — per-user engagement lookup
• (platform, created_at DESC) — per-platform breakdown

principal_id is ON DELETE SET NULL so principal removals don't blow away historical engagement records.

New TypeID prefix widget_event registered in packages/ids.

Verification

• bun run db:migrate against a fresh Postgres applies cleanly through 0066
• Re-running is idempotent
• \d widget_events confirms table + 4 indexes + FK to principal

Follow-ups (separate PRs)

1. POST /api/analytics/widget-event ingestion endpoint (rate-limited, CORS-aware)
2. Widget SDK wiring (packages/widget) to fire lifecycle events, gated by config flag
3. Admin dashboard chart for per-platform widget engagement
4. iOS SDK parity for the same lifecycle signals

Happy to split or merge follow-ups differently based on what's most useful.

Notes

• Hand-written SQL migration to match the convention used by other named migrations in drizzle/ (e.g., 0064_post_mentions.sql, 0029_feedback_indexes.sql)
• No app code touched in this PR — safe to land independently of any in-flight widget work