clang-tidy: parse against libc++ everywhere, and document the real hook setup

[helly25]

Two parts of the same story: making clang-tidy behave identically on macOS and Linux, and describing the setup honestly in the README.

1. Parse against libc++ on every platform

compile_commands-update.sh extracts the compile DB from the default build configuration — --config=clang never reaches the extractor's aquery; we only substitute the compiler binary afterwards via --bcce-compiler. So the recorded commands carry no -stdlib, and the hermetic clang falls back to each platform's default:

platform	standard library
macOS	libc++ (the hermetic toolchain's own)
Linux	libstdc++

Same clang-tidy, different standard library, therefore different template instantiations and different findings. A finding fixed on a Mac could simply be absent on the Linux CI runner, and the reverse — which makes the finding sweep platform-dependent and would make enforcement flap between local and CI.

Fix: pass --bcce-copt=-stdlib=libc++. The hermetic toolchain ships libc++ on both platforms, so this is a no-op on macOS and the actual switch on Linux.

Test: all 3002 compile DB entries carry the flag; clang-tidy still parses cleanly on macOS with no hard errors. The Linux half is exactly what this changes, and the CI clang-tidy job verifies it.

This treats the symptom

The root cause is that the DB is extracted in the default configuration with only its compiler replaced. Extracting with --config=clang (a refresh_compile_commands target with targets = {"@//...": "--config=clang"}) would make every flag — stdlib, include paths, feature macros, sysroot — match what bazel actually builds, and would let both --bcce-compiler and this flag go away. Worth doing; tracked separately.

2. README: document the dev hook setup that actually exists

The dev-setup paragraph claimed the repo "enables trunk-fmt-pre-commit and trunk-check-pre-push so the hooks run automatically once installed". That has been false for some time: both actions are disabled in .trunk/trunk.yaml, and main.yml's "Trunk must not own git hooks" step fails the build if either is re-enabled. A dev following the README would never run pre-commit install and would end up with no git hooks at all.

It now says what is there: pre-commit owns the git hook and delegates trunk fmt to trunk, trunk's own hook actions stay disabled so the two cannot fight over .git/hooks, and CI runs pre-commit, trunk check and clang-tidy as separate jobs. clang-tidy is one of the pre-commit hooks too — it moved there from trunk, which pinned a version too old to parse this code — opt-in for now and automatic once the finding sweep lands.

This paragraph originates in #183, which proposed it before the CI guard and the clang-tidy job existed. The rest of that PR is superseded and it is being closed.