build: audit zccache per-TU cache keys for cross-runner stability

[zackees]

Problem

zccache is fbuild's per-TU object cache. fbuild dispatches compiler invocations through it via wrap_args in crates/fbuild-build/src/zccache.rs:167-178. zccache keys entries via a hash of the wrapped command (and presumably input-file content).

The command-line passed to zccache typically includes absolute paths: -I/home/runner/.fbuild/packages/.../include, source files /home/runner/work/fbuild/fastled/.../sketch.ino.cpp, output targets -o /home/runner/work/fbuild/fastled/.build/.../foo.o. If any of those path strings contribute to zccache's cache key, cross-runner reuse fails even when every input is content-identical and the compiler version is stable.

We need to know whether this is a real problem before designing around it.

Sub-task of #147.

Actions

1. Read zccache source (upstream zackees/zccache): identify exactly which parts of the wrapped command contribute to the cache key. Document findings in a comment on this issue.
2. Classify:
   • If absolute paths are excluded or normalized → nothing to do here; close.
   • If absolute source / output paths are baked in → file upstream issue on zackees/zccache, then either (a) add normalization in fbuild's wrap_args as a workaround, or (b) wait for upstream fix.
3. Integration test: add crates/fbuild-build/tests/zccache_hit_across_workspace_rename.rs that compiles the same project from two different absolute paths on the same runner and asserts the second compile produces a zccache hit (count via ZCCACHE_LOG or a stats endpoint).

Out of scope

• zccache config / daemon tuning.
• mtime handling in zccache (should be content-based via blake3 per the upstream docs, but worth confirming as part of step 1).

Related

• [META] fbuild build cache must survive CI tar-extract / cross-runner restore #147 — meta.
• build: absolute filesystem paths baked into cache keys — breaks cross-runner / cross-workspace reuse #148 — absolute paths in fbuild's own cache keys (parallel concern, different layer).
• daemon/setup: expose zccache store location so consumer workflows can actions/cache it #149 — setup action exposing zccache store path (depends on the answer here for whether caching the store is even useful cross-runner).

[zackees]

Documented findings and fix are in PR #191: #191

Audit result: upstream zackees/zccache normalizes C/C++ source/include/header paths relative to the request key_root, and the daemon sets that key_root from the compile request CWD. Output paths are not part of the per-TU key, so fbuild needs to invoke zccache from a stable workspace root for cross-runner/cache reuse.

Primary upstream references:

• path normalization for context keys: https://github.com/zackees/zccache/blob/b0436da318f109f1180ee78b8392d137523f39e2/crates/zccache-depgraph/src/context.rs#L116-L131
• artifact key path normalization: https://github.com/zackees/zccache/blob/b0436da318f109f1180ee78b8392d137523f39e2/crates/zccache-depgraph/src/context.rs#L195-L210
• daemon registering C/C++ context with CWD as key_root: https://github.com/zackees/zccache/blob/b0436da318f109f1180ee78b8392d137523f39e2/crates/zccache-daemon/src/server.rs#L2783-L2787
• upstream tests covering output path independence / workspace rename reuse: https://github.com/zackees/zccache/blob/b0436da318f109f1180ee78b8392d137523f39e2/crates/zccache-daemon/tests/stress_test.rs#L708-L745 and https://github.com/zackees/zccache/blob/b0436da318f109f1180ee78b8392d137523f39e2/crates/zccache-daemon/tests/stress_test.rs#L757-L838