perf(build): decide fate of core-cache-hydrate after fw-libs zccache fix #995

Context

#952 bundled two concerns from the #942 performance audit:

• warm fresh-project fw-libs recompiling for ~150s
• core-cache-hydrate recording 0 ms while core objects were stored and then never hydrated

The first concern is resolved by #987/#986: the #942 harness showed warm fw-libs dropping from 152s to 2.2s, with sketch/core/fw-libs all hitting zccache cross-project.

The remaining core-cache-hydrate question was explicitly called out in #952 as secondary. It is not needed for the warm-path win once zccache is hot, but it was not proven fixed or intentionally removed.

Task

Decide what should happen to the core-cache-hydrate path now that the real warm-path bottleneck is fixed.

Acceptance criteria

• Reproduce or disprove the stale observation with a cold-zccache/fresh-project harness run.
• If core-cache-hydrate is still useful, make the hydrate hit for identical core config and document before/after numbers.
• If it is obsolete because zccache covers the case better, remove or de-emphasize the misleading metric/cache path and document the rationale.
• Link the outcome back to perf(build): framework libs (~150s) recompiled per project; core cache never hydrates #952 and meta: reconcile residual #942/#974 follow-ups after #974 close-out #992.