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

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).