feat(analytics): send private events from the web app

[rabble]

Summary

• Send the seven agreed analytics events in the version-two format.
• Send landing and registration events without requiring a login.
• Sign user-linked events while keeping the user's public key outside the analytics event.
• Record one impression after a video stays at least half visible for one second.
• Record one playback summary when the viewer leaves the video or backgrounds the page.
• Keep the existing public Nostr view count unchanged.
• Keep production collection explicitly off.

Why

The old browser events do not match the shared contract and include fields that the new privacy design does not store. This makes browser, mobile, and server events agree, keeps retries safe, and removes queued data when consent or accounts change.

Related issue

Implements the web work in divinevideo/divine-funnelcake#1090 and docs/plans/2026-08-19-open-source-analytics-platform.md.

Current staging state

• The exact preview for this head is live at https://81ad1fd2.divine-web.pages.dev and returns HTTP 200.
• The Funnelcake staging endpoint and storage path are live. A separate automatic check already proved API → restricted writer → ClickHouse → read-only health view.
• Staging collection was turned off again after that check. Production collection remains off.
• The real preview journey still needs the page to run in a browser while staging is temporarily enabled. The available browser runner has no browser installed, so I have not claimed that an HTTP fetch proves a browser-created event.

The staging checker creates a unique preview link and waits for the exact landing_viewed event. This can run before any pull request merges; the reviewed staging settings can be enabled for the check and removed immediately afterward.

Validation

• npm run analytics:contract:check passed.
• npm test passed with 2,300 tests.
• Type checking, lint, and the production build passed.
• The preview deployment passed and the live preview returns HTTP 200.
• All GitHub checks are green.
• Manual browser-created staging event: pending a usable browser session and temporary staging enable window.

Visual change

None. This changes background event delivery only.

[cloudflare-workers-and-pages]

Deploying divine-web with    Cloudflare Pages

Latest commit:	bfb9b0f
Status:	✅  Deploy successful!
Preview URL:	https://81ad1fd2.divine-web.pages.dev
Branch Preview URL:	https://feat-product-analytics-v2.divine-web.pages.dev

View logs

[github-actions]

🚀 Preview Deployment

Last updated: 2026-08-20T11:59:28.507Z

Property	Value
Preview URL	https://e453d7bf.divine-web-fm8.pages.dev
Commit	bfb9b0f
Branch	feat/product-analytics-v2
Workflow run	#1213

[rabble]

The analytics staging test can now use this existing Cloudflare preview; no new divine.video name is needed:

https://d4743ee4.divine-web-fm8.pages.dev

On that preview, open Settings → Moderation, show the debug information, and choose Staging for the Funnelcake API. Analytics stays off on ordinary previews and on all *.divine.video pages unless the build explicitly enables it.

The full web check passed locally, and GitHub CI is green: https://github.com/divinevideo/divine-web/actions/runs/32365847241

The live journey cannot pass yet because the staging Funnelcake analytics route still returns 404. The preview is ready for the route deployment rather than pretending that the end-to-end test has passed.

[rabble]

The current tested preview is:

https://e453d7bf.divine-web-fm8.pages.dev

The Staging choice now takes effect immediately; no reload is needed. To create the browser event after the staging backend is deployed:

1. Open the preview and allow analytics cookies.
2. Open Settings → Moderation → Show debug information.
3. Choose Staging for the Funnelcake API.
4. Return to the home page using the unique link printed by the staging verification command.

All 2,303 web tests and the production build pass locally. The new GitHub checks and preview deployment are also green.