[chore] Dogfood: switch the marketing site from Fathom to ghostanalytics

Problem

The marketing site tracks itself with Fathom — config/analytics.ts:10-22 sets driver: "fathom". We should be our own first customer.

Proposed fix

Once the app is deployable, point the marketing site at a ghostanalytics site id and remove the Fathom driver. Good dogfooding + a credibility signal.

Priority: P2.

From the 2026-07-20 privacy-first competitive audit (vs. Plausible / Fathom / Simple Analytics / Umami).

The premise here is wrong, and it makes the task bigger than the title suggests.

There is no Fathom tag on the marketing site to switch away from. config/analytics.ts:11 does say driver: 'fathom', but that key configures the framework's third-party analytics driver and is not wired to the rendered pages — #11 already noted this in passing. The marketing layout ships exactly one script:

$ grep -n '<script' resources/layouts/marketing.stx
63:<script src="/assets/scripts/site-mode.js" defer></script>

That is the coming-soon gate. There is no tracker of any kind on the site.

So this is not "switch from Fathom to ours" — it is "install our own tag on our own site for the first time", which is a stronger dogfooding story and a slightly different job: create a site record, get the script tag, add it to the marketing layout, and confirm events land.

Worth retitling.

Shipped in f884327.

config/analytics.ts declared driver: 'fathom' with a real Fathom site id — a competitor's tracker configured on the site whose /compare pages argue against handing visitors to third parties. It never loaded (nothing read that file), so the effect was not a leak but a config that read like a decision nobody had taken, on a product that measured nothing about itself.

The tag now comes from stx's analytics block in config/ui.ts, rendered by injectAnalytics():

• driver: 'custom' pointed at public/script.js — the artifact customers install — rather than stx's built-in self-hosted generator, which emits its own beacon with a payload /collect does not accept.
• Off unless ANALYTICSHQ_SITE_ID is set, so dev and fresh checkouts beacon at nothing.
• Global scope is safe here specifically: every app route is a fixed path (no [param] routes) and the tracker sends location.origin + location.pathname, so query strings are dropped and no customer site id can reach a recorded path.

Verified in a browser with the id set: script.js 200, exactly one /collect beacon per page returning 204, window.analyticshq exposed.

The third-party guard was widened to match — it swept templates and public/, so a config-injected tag involved no markup and it would have called this clean the entire time.