chore(deps): cascade latest running-process and zccache releases into fbuild

[zackees]

Context

fbuild embeds zccache and also depends directly on running-process. Both dependency paths must resolve the exact same running-process git revision, not merely the same semver, because running-process defines unmangled rp_*_public native symbols. Resolving two package identities can link two copies of those symbols into fbuild.

Current fbuild dependency chain:

• zccache: 5ee292ff61e0f5909e1893916efe3bd963db8032 (1.12.17)
• running-process: 59556ebbb779a66a95811c75bb1533cf3db1c525 (4.6.4 in Cargo.lock)

Latest upstream snapshot at issue filing:

• running-process main and published 4.8.0: 0374db2b2d3d9f4b4bb8db7c9372855853316f2f
• zccache main: 5388fd248395428b624f7d9d4055132870b27933
• latest published zccache: 1.13.0 at 44e9682d5085e471101b3a9a356b91c6532d528a

Current zccache main still pins the old running-process SHA. The dependencies therefore cannot be upgraded independently: the release must cascade from running-process through zccache and finally into fbuild.

This issue covers the latest dependency cascade and exported-symbol correctness. Broker v2 adoption and cache-telemetry integration remain separate follow-ups.

Proposal

At the start of implementation, refresh both upstream repositories to their latest main commits and record the selected SHAs. Freeze those SHAs for the duration of the cascade so the target does not move midway through release work.

1. running-process

   • Select the latest main commit available when the cascade begins.
   • If that exact commit is not already covered by a published release, bump the version, tag it, and publish a new running-process release.
   • Record the exact release commit used downstream.
   • As of filing, 4.8.0 at 0374db2b... already satisfies this gate.

2. zccache

   • Begin from the latest zccache main, not merely the existing 1.13.0 tag.
   • Update its running-process dependency to the exact selected release SHA and matching semver.
   • Update its lockfile and validate embedded/client paths.
   • Tag and publish a new zccache release containing both the latest zccache changes and the new running-process pin.

3. fbuild

   • Repin every zccache dependency to the new zccache release commit.
   • Repin the workspace running-process dependency to exactly the SHA used by that zccache release.
   • Update Cargo.lock and dependency comments.
   • Preserve the existing client-async feature selection unless separately justified.

4. Regression guard

   • Add an automated dependency-graph check that fails if more than one running-process package identity, source, or revision is resolved.
   • Mechanically verify that fbuild's direct running-process revision equals the revision selected transitively by zccache.

Acceptance criteria

• The selected running-process SHA was the latest upstream main when the cascade began.
• That exact running-process SHA has a published release.
• The selected zccache base was the latest upstream main when its release work began.
• A new published zccache release pins the selected running-process release SHA.
• All fbuild zccache dependencies point to that new zccache release revision.
• fbuild's direct running-process dependency uses exactly the SHA pinned by zccache.
• Cargo.lock contains exactly one running-process package identity/source/revision.
• An automated guard fails when the direct and transitive revisions diverge.
• Final fbuild binaries link without duplicate rp_*_public symbols.
• Existing broker behavior and daemon request handling continue to work.
• Embedded zccache compilation demonstrates a cold miss followed by a warm hit.
• soldr cargo check --workspace --all-targets passes.
• soldr cargo clippy --workspace --all-targets -- -D warnings passes.
• Targeted broker and embedded-zccache tests pass.
• Cross-platform CI passes on Windows, Linux, and macOS.