feat(analytics): GPC-gated PostHog with pageviews + waitlist events

[MP2EZ]

Summary

Adds PostHog product analytics to being.fyi — the first analytics ever on the site. Tight scope, structurally GPC-gated, EU data residency. Output of a 5-agent review sequence (compliance → product → architect → product priority → compliance).

What ships

Events (3 total):

• `$pageview` (PostHog default)
• `waitlist_signup_submitted { source }`
• `waitlist_signup_failed { source, reason }`

Explicitly excluded: autocapture, session replay, heatmaps, surveys, email-hash identify (PR #2), cta_clicked / crisis_resource_clicked / ab_variant_assigned (PR #2+).

GPC structural kill

`AnalyticsGate` (client component, `useSyncExternalStore`) returns `null` when ANY of:

• `being_gpc=1` cookie (set by middleware on `Sec-GPC: 1`)
• `navigator.globalPrivacyControl === true` (browsers exposing JS API without HTTP header)
• `NEXT_PUBLIC_POSTHOG_KEY` missing (local dev = graceful degradation)
• SSR (server snapshot = suppress = safe default)

Null → `PosthogProvider` never mounts → dynamic `import('posthog-js')` never fires → posthog-js chunk never fetched → no init, no `ph_*` cookie, no beacon. Not "suppressed after load" — structurally never loads.

Why client-side, not server-side (deliberate divergence from architect's design)

The architect designed `AnalyticsGate` as a server component using `cookies()` from `next/headers`. I implemented client-side because the server-side approach would force the parent layout into dynamic rendering, undoing `force-static` on legal pages and re-introducing the per-request `marked()` parse PR #33 fixed.

Verified:

• Build output: all 16 routes still `○ (Static)` including `/privacy/multi-state`, `/cookies`, etc.
• 6 unit tests pass including the structural regression gate
• Compliance re-review confirmed equivalence: "client-side gate satisfies the structural commitment; `useSyncExternalStore` fires the client snapshot synchronously on hydration before any `useEffect` in PosthogProvider can run"

CI structural-regression gate

`tests/analytics-gpc-gate.test.tsx` test #6 is a grep gate: if any file under `app/`, `components/`, `lib/` statically imports `posthog-js` outside `PosthogProvider.tsx`'s dynamic import, the build fails. This is the regression vector that would bypass the gate by getting posthog-js into the page bundle. Locked in CI.

CSP additions

```
script-src += eu-assets.i.posthog.com
connect-src += eu.i.posthog.com eu-assets.i.posthog.com
img-src += eu.i.posthog.com (PostHog pixel fallback)
worker-src 'self' blob: (PostHog web worker for batching, even with replay off)
```

/cookies page rewrite

• ❌ "No PostHog" denial removed (was false the moment this ships)
• New headline: "Two Functional Cookies + Privacy-Respecting Analytics"
• New `ph_*` disclosure: EU Frankfurt, 365-day, kill conditions, scope clearly stated
• "What We Don't Use": explicit "no autocapture" + "no session replay (PostHog can do these — we have them turned off)"
• GPC section: rewritten to describe what the kill actually suppresses (was previously "we don't use third-party analytics" which is no longer true)

Hard dependencies — DO NOT MERGE until satisfied

1. docs(legal): scope §5.2 analytics to in-app vs web (PostHog on being.fyi) being#106 (privacy policy §5.2 split + Notion §5.1 disclosure) must land on `being@development` first
2. `POSTHOG_KEY` GitHub Actions secret must be set in repo settings before merge (graceful degradation if missing — AnalyticsGate renders null — but no events captured)
3. PostHog EU project must exist (the user needs to create a project at app.eu.posthog.com if they haven't already)

If items 2 or 3 are unsatisfied, the PR can still merge — `isPosthogConfigured()` will return false, AnalyticsGate renders null, no errors, no broken pages. Set them when ready.

Verification

• `npm run lint` — clean
• `npm test` — 80 tests pass (6 new GPC-gate tests)
• `npm run build` — all 16 routes still static, posthog-js in dynamic chunks (not main bundle)
• curl: `/home` returns 200 with new CSP. `Sec-GPC: 1` → middleware sets `being_gpc=1` + `X-GPC-Honored: 1` (existing PR feat(privacy): add Sec-GPC server-side detection + cookie policy update #32 behavior intact)
• curl: `/cookies` headline now reads "Two Functional Cookies + Privacy-Respecting Analytics"; `ph_*` row present
• Compliance agent re-review of full diff — conditional sign-off pending the 3 hard dependencies above (all now addressed)

Manual launch-day verification (after PR + upstream both merged + secret set)

• Load `https://being.fyi/home\` in regular Chrome → DevTools Network shows posthog-js loads + `/decide` POST + `$pageview` capture
• Load same URL in Brave (sends GPC) → DevTools Network shows NO posthog-js fetch, NO eu.i.posthog.com requests, NO `ph_*` cookie
• Submit waitlist form → `waitlist_signup_submitted` event appears in PostHog dashboard with `source` property

Out of scope (PR #2+)

• `cta_clicked`, `crisis_resource_clicked`, `ab_variant_assigned` events
• Email-hash identify (server-side SHA-256 + `identifyByEmailHash` helper) — requires another §5.2 update before shipping
• PostHog feature flags / experiments (we keep `being_ab_variant`)
• Session replay / heatmaps / surveys (categorically off per /cookies disclosure)

🤖 Generated with Claude Code