sr-ht-compare-jdq Untrack the compiled CSS/JS bundle that make css deletes in sourcehut-compare Lined Up

What is wrong: sourcehut-compare/web/static/main.min.79713f25.css (142 KB) and web/static/bundle.a62c2e63.js (10 MB) are both tracked in git, while sourcehut-compare/.gitignore already has the patterns /web/static/main.css and /web/static/main.min.*.css (with a NOTE that removal from the index 'waits on the first CI run'). A tracked file is unaffected by a later-added ignore pattern, and 'make css' opens with 'rm -f web/static/main.css $(CSS)' — it deletes a tracked file.

Why it matters: every developer who runs 'make css' gets a dirty working tree, and Go stamps every binary built afterwards vcs.modified=true, which is exactly what check-version exists to catch — and compare is one of the four repos that has no check-version target (see D12/sr-ht-compare issue for that). Separately, install-files copies web/static/*, so a stale tracked CSS would be staged if make css is skipped.

Correct variant: the seven sibling services, all of which gitignore the compiled stylesheet and cannot hit this class of bug.

Fix: git rm --cached web/static/main.min.79713f25.css (the ignore entry already exists). Separately decide whether the 10 MB esbuild bundle from frontend/ (web/static/bundle.a62c2e63.js) should be built in CI like the CSS rather than committed, and gitignore it too if so.

Audit: D09 (cross-repo audit, 2026-08-17)