chore: remove zccache crate linkage and use the managed sidecar for cache APIs #600

Context

fbuild already treats zccache as a managed runtime sidecar for compiler caching:

• crates/fbuild-build/src/managed_zccache.rs pins MANAGED_ZCCACHE_VERSION = 1.12.7, downloads release binaries into ~/.fbuild/<mode>/bin/zccache-<ver>/, and returns the zccache executable path.
• crates/fbuild-build/src/zccache.rs discovers FBUILD_ZCCACHE_BIN, the managed sidecar, or an ambient zccache binary, then invokes commands such as zccache start, zccache wrap, and zccache fp ... by spawning the binary.

But the workspace still compiles zccache library crates into fbuild:

• root Cargo.toml has zccache-artifact = 1.9.
• Cargo.lock resolves zccache-artifact, zccache-core, and zccache-hash at 1.9.0.
• crates/fbuild-build/src/framework_libs.rs imports zccache_artifact::KvStore.
• crates/fbuild-library-select/src/cache.rs imports zccache_artifact::{Key, KvError, KvStore}.

That means fbuild is partly coupled to zccache as a compile-time Rust dependency even though the intended architecture is a sidecar binary boundary.

Proposal

Remove zccache-artifact and its transitive zccache crates from fbuild's compile graph. Any functionality that currently uses zccache_artifact::KvStore should move behind a sidecar-backed boundary or an fbuild-owned minimal cache abstraction.

Preferred direction:

1. Keep zccache itself as a runtime sidecar binary, resolved by the existing managed sidecar flow.
2. Replace direct Rust imports of zccache_artifact::{Key, KvError, KvStore} with either:
   • sidecar CLI calls if zccache exposes the needed K/V operations, or
   • a small fbuild-local disk cache abstraction for fbuild-specific memoization if the data is not actually zccache-owned.
3. Remove zccache-artifact = 1.9 from workspace dependencies and update Cargo.lock so no zccache-* crates are compiled as part of fbuild unless independently justified.

Acceptance criteria

• cargo tree --invert zccache-artifact reports no fbuild consumers.
• Cargo.toml no longer declares zccache-artifact as a workspace dependency.
• Cargo.lock no longer contains zccache-artifact, zccache-core, or zccache-hash solely due to fbuild crates.
• Existing runtime behavior remains: fbuild still finds/downloads/runs the managed zccache sidecar for compiler wrapping and fingerprint operations.
• Framework/library selection cache behavior remains covered by tests, either through the new sidecar-backed path or an fbuild-owned cache implementation.

Related issues

• Proposal: first-class fbuild cache save / restore for toolchains + platforms + framework + zccache sidecar #527 is related but broader: it tracks first-class fbuild cache save / restore and zccache sidecar delegation for archive workflows. This issue is narrower: remove zccache Rust crates from fbuild's compile-time dependency graph.