ci: gate speed — measured, plus the zero-tracking gate #271 was missing

[important-new]

Ten commits. Every change was measured before shipping, and two of them
contradicted the prediction that motivated them.

Closes the last open task on #271

#271 Task 5 — make the zero-client-tracking posture enforceable. The
report-view counter is defensible precisely because the browser reports nothing;
that posture is why the LIA holds, and it lived only in a document.

The plan's own pre-dispatch audit said the drafted rule set was miscalibrated,
and it was right: as written it flagged four legitimate things (a theme cookie, a
visibilitychange revalidate, an IntersectionObserver, an offscreen Image used
to decode a crop source). A gate that cries wolf on ordinary UI code gets
switched off, so the rules target only the mechanisms by which a browser SENDS:
navigator.sendBeacon, analytics globals, and a pixel whose interpolated src
nothing ever loads or decodes.

Expectation derived by running it rather than copying the audit's list — that
list had already drifted. 976 client files, zero findings. Proven red once per
rule before wiring in.

Speed, measured

	before	after
eslint	cold 442s	warm, 1 file 6s
test:unit shard 1/4	(422s whole)	148s
test:web shard 1/4	(159-181s whole)	55s
test:types typecheck	237.7s	6.9s
e2e	357s	~264s

Projected wall clock ~7.5min → ~5min, with two fewer runners.

test:types recompiled the entire server to check four files — its tsconfig
extends the api config AND re-lists server/**/*. That was an oversight from
the project-references work: the app config was converted to consume the emitted
.d.ts and this one was only stopped from fighting over the output directory.

type-check (api) was a second runner for the same answer. Once app and api
became project references, type-check:app IS tsc -b tsconfig.json, which
builds api and reports its errors. Verified before deleting: a type error planted
in server/api/admin.ts, which the app program does not import, is reported with
exit 2.

Costs, stated

• Total runner time goes UP. Sharding takes npm ci from 10 runners to 16;
  splitting e2e adds a second browser install and a second worker build.
• The e2e estimate was wrong the first time. The second Playwright config had
  been reusing the first's worker; standalone it must boot one, so 112s becomes
  192s and the split is −26%, not −33%.

Checked rather than assumed

• ESLint's default cache strategy is metadata and a fresh checkout renews every
  mtime — the widely reported "the cache does nothing on Actions". This repo
  already passes --cache-strategy content; that flag is load-bearing and the CI
  comment now says so.
• A matrix job aggregates into ONE needs entry, so verify still catches a
  single red shard. verify is the only required check, so the renamed jobs do
  not strand branch protection.
• ⚠️ upload-artifact@v4 FAILS on a duplicate artifact name, so the e2e report
  name is keyed on the matrix id.
• Playwright re-runs a project's dependencies in EVERY shard
  ([BUG] Setup file runs for each shard on Github microsoft/playwright#21974) — that is why e2e is split, not sharded.
• The seeded e2e config spreads ...base, so it can boot its own worker. Proven
  by running it standalone against a wiped .wrangler/state: 9 passed, exit 0.
• A ref-deletion push no longer pays for a full build: the hook's fail-safe could
  not tell "this push deletes refs" from "I cannot tell what this push contains".

❌ .tsbuildinfo deliberately NOT cached: tsc --build is documented to miss
breaking type changes from a dependency update when a build-info exists and to
report success with type errors present (microsoft/typescript-go#2666).

Full suite green locally: lint (28 gates), test:unit 723/5236, test:web 335/2232.

⚠️ None of the CI wiring is verified until this PR runs it. Every number above is
component-level and local.

🤖 Generated with Claude Code