[privacy] Review fingerprint surface: screen dimensions & page title

Problem

We collect screen_width/screen_height (routes/analytics.ts:227-228) and page title (:211). Screen size is a weak fingerprint signal; title can leak page content.

Why it matters (privacy-first)

Individually low-risk and not combined into an identifier today, but they widen the surface. Worth a deliberate keep/drop decision rather than collecting by default.

Proposed fix

Confirm each has a reporting use (screen → device-class buckets rather than raw px?; title → needed vs. path?). Bucket or drop what is not needed.

Priority: P2.

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

Done in c68c7f3.

All three fields — document.title, screen.width, screen.height — are removed rather than bucketed, because the keep/drop question the issue asks for turned out to have an unambiguous answer: nothing read any of them.

Verified before touching anything: every SELECT in routes/analytics.ts is column-explicit and none names them, there is no SELECT * in routes/ or app/, and device_type is derived from the User-Agent (info.deviceType), not from screen size. So there was no reporting use to preserve — bucketing screen size into device classes would have been building a consumer for data we had already decided we did not need.

On title specifically: the issue notes it "can leak page content". On a customer's app that is not hypothetical — "Invoice #4432 — Jane Smith", "Reset password for alice@example.com" — and we stored it in a varchar(255) indefinitely while telling visitors on our own comparison pages that we hold no personal data. The path already identifies the page for every report we have.

Migration 37 drops the columns, so the already-collected rows go too. Stopping collection alone would have left the liability sitting in the table.

7 sabotage-checked tests pin it, including one guarding the opposite direction so the removal cannot quietly widen.

Follow-up: if page titles are ever wanted for a report they should return as a per-site opt-in, never a default — #11 is the natural home for that toggle.