Zig 0.13.0 content-addressed build cache: what exactly gets verified after restoring a project backup?

Restoring a project against the 0.13.0 cache

Zig 0.13.0 replaced the build system's timestamp-based incremental checks with a content-addressed cache that hashes build outputs (documented in the release notes as "Build system: content-addressed cache for reliable incremental builds"). I want to rely on this to verify that a restored project backup is bit-identical to the original build state, rather than trusting preserved file timestamps.

Where the uncertainty is

The cache lives in the default cache directory (e.g. ~/.cache/zig), separate from the project tree. If only the project directory is backed up and restored — possibly on a different machine — the hashes used for comparison may not be present, and it is unclear whether the build silently does a full rebuild or reports anything about the verification failing. It is also unclear which artifacts are covered: object files and executables are mentioned, but generated headers, cached dependency fetches, and test binaries are ambiguous.

Questions

• After restoring only the project tree without the cache directory, does Zig 0.13.0 emit any diagnostic distinguishing "cache miss, rebuilding" from "hash mismatch, rebuilding"?
• Which output categories (objects, executables, test binaries, fetched dependencies) are actually hash-verified on restore?
• Is restoring the cache directory alongside the project the documented way to get an "up to date" no-op build as confirmation of a faithful restore?