Fix stale dependent framework caches by propagating dependency cache keys

[ikesyo]

Summary

This PR fixes stale cache reuse for dependent frameworks by including dependency build state in cache keys.

Previously, a downstream target could keep reusing a cached artifact even after a dependency was rebuilt with incompatible changes.

Related issue: #265

What Changed

• Added dependencyCacheKeyChecksums to SwiftPMCacheKey.
• Added graph-based cache key calculation (calculateCacheKeys(for:)) that computes keys in dependency order and embeds direct dependency key checksums.
• Updated framework cache flows to reuse a single cache-key map across existing framework validation, restore checks, cache writes, version file generation, and restored cache sharing.
• Preserved backward compatibility for old version files by decoding missing dependencyCacheKeyChecksums as an empty list.
• Stabilized dependency checksum ordering with a deterministic tie-breaker (targetName, then checksum).
• Kept historical behavior when cache policies are empty (cache feature is fully off).
• Fall back to building without cache participation when cache key precomputation fails, so missing local repository metadata does not abort the build before the intended build path.

Tests

• Extended CacheSystemTests to cover encoding with dependency checksums, backward-compatible decode, direct dependency checksum propagation, and dependent key invalidation when dependency build state changes.
• Updated cache key tests to copy the PartialCacheTestPackage fixture into a temporary tagged git repository, keeping them stable in CI merge checkouts.
• FrameworkProducerTests passes locally.
• CI is passing.

Impact

• Dependency changes now correctly invalidate dependent cache keys.
• Reduces risk of link/runtime failures caused by stale downstream cache artifacts.
• Maintains existing non-cache behavior for packages whose cache keys cannot be resolved.

[giginet]

Thanks for the fix — the propagation approach via dependencyCacheKeyChecksums looks right and the backward-compatible decode is well handled. Two concerns I'd like to raise before merging.

1. precomputeCacheKeysIfPossible swallows all errors silently

} catch {
    logger.warning(
        "⚠️ Cache key precomputation failed. Continue build without cache restore/save for this run.",
        metadata: .color(.yellow)
    )
    return [:]
}

Previously, errors from calculateCacheKey(of:) such as revisionNotDetected, compilerVersionNotDetected, and xcodeVersionNotDetected would propagate and abort the build. With this change, any error falls back silently to a "cache fully disabled" mode for the whole run. Two problems:

• The warning does not include the underlying error, so a user running prepare mode on a large dependency tree has no way to discover why caching was silently disabled. They will just observe slow rebuilds.
• The catch is too broad. If the intent is to tolerate missing git metadata in fixtures (as the PR description says), only Error.revisionNotDetected should warrant the fallback. compilerVersionNotDetected / xcodeVersionNotDetected indicate genuinely broken environments and should still abort.

Suggested changes:

• At minimum, include error.localizedDescription (or \(error)) in the warning so users can diagnose.
• Narrow the catch to the specific case(s) that justify a fallback and rethrow the rest.
• Optionally, gate the fallback behind a CLI flag so strict cache validation can remain the default.

2. Cache key precomputation is now fully serialized

calculateCacheKeys(for:) iterates graph.allNodes and awaits each calculateCacheKeyRecursively call sequentially. Each call internally spawns subprocesses for clang --version, xcodebuild -version, git describe, and git rev-parse. Previously these were invoked inside withTaskGroup blocks in validateExistingFrameworks / restoreCaches / shareCachesToStorage and ran in parallel across targets. For projects with many dependencies this could regress wall-clock time noticeably.

Suggested changes (in order of effort/payoff):

• clangVersion and xcodeVersion are constants for the lifetime of a Scipio run. Fetch them once (e.g. at CacheSystem initialization or at the start of calculateCacheKeys(for:)) and reuse, instead of re-running the subprocesses for every target. This is cheap and recovers most of the regression.
• Parallelize same-level dependencies inside calculateCacheKeys(for:) while preserving topological ordering — for example, processing the graph layer by layer with withTaskGroup.

The first one alone is low-risk and a clear win.

[ikesyo]

@giginet Thanks for the feedback. I addressed the points. Please re-review the changes.

520a4eb...df83ef2

[Ckitakishi]

LGTM, thank you!