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

README.md

@@ -322,7 +322,9 @@ The project only comes with a Bazel BUILD.bazel file and can be added to other B
 
 The project is formatted with specific clang-format settings which require clang 16+ (in case of MacOs LLVM 16+ can be installed using brew). For simplicity in dev mode the project pulls the appropriate clang tools and can be compiled with those tools using `bazel [build|test] --config=clang ...`.
 
-Lint and format are driven by [Trunk](https://docs.trunk.io/cli). Devs are **required** to install the CLI locally — `curl https://get.trunk.io -fsSL | bash` — then run `trunk check` and `trunk fmt` before pushing. The repo enables `trunk-fmt-pre-commit` and `trunk-check-pre-push` so the hooks run automatically once installed. CI runs `trunk check` only (no auto-fixing on the GitHub side); failing lint must be fixed locally and re-pushed.
+Lint and format are driven by [Trunk](https://docs.trunk.io/cli) plus [pre-commit](https://pre-commit.com). Devs are **required** to install both — `curl https://get.trunk.io -fsSL | bash` and `pip install pre-commit` (or your package manager's equivalent) — then run `pre-commit install` **once**. pre-commit is this repo's single git-hook entry point and delegates `trunk fmt` to trunk on every commit; trunk's own git-hook actions are deliberately disabled in `.trunk/trunk.yaml` so the two cannot fight over `.git/hooks` (a CI check fails the build if they are re-enabled). CI runs `pre-commit`, `trunk check` and `clang-tidy` as separate jobs and never auto-fixes; failing lint must be fixed locally and re-pushed.
+
+`clang-tidy` is one of these pre-commit hooks as well — it moved there from trunk, which pinned a version too old to parse this code. It is opt-in for now (`pre-commit run clang-tidy --all-files --hook-stage manual`) and becomes automatic like the rest once the finding sweep lands. See [STYLE_CPP.md](STYLE_CPP.md) for how to run it and how to build the `compile_commands.json` it needs.
 
 ### MODULES.bazel
 

compile_commands-update.sh

@@ -71,6 +71,16 @@ fi
 # exec configuration keep their command, so nothing leaves the compile DB.
 declare -a BCCE_ARGS=("--bcce-compiler=${CLANG}" "--bcce-prefer-target-config")
 
+# Parse against libc++ on EVERY platform, so clang-tidy sees the same standard
+# library everywhere. The extracted commands come from the default build
+# configuration, not `--config=clang`, so they carry no `-stdlib`; the hermetic
+# clang then falls back to each platform's default - libc++ on macOS, libstdc++
+# on Linux. That made the same check report differently per platform: a finding
+# fixed on a Mac could be absent on the Linux CI runner and the reverse. The
+# hermetic toolchain ships its own libc++ on both, so asking for it is enough
+# (a no-op on macOS, the actual switch on Linux).
+BCCE_ARGS+=("--bcce-copt=-stdlib=libc++")
+
 # The hermetic clang carries its own libc++ but no system C headers: without the
 # SDK sysroot its <locale> support headers fail on `'time.h' file not found`.
 # The bazel `--config=clang` toolchain supplies this itself; the extracted