Fix CI cache key and release dependency chain

[bguidolim]

Summary

• Fix SPM cache key: use Package.swift instead of Package.resolved (gitignored, so hashFiles returned empty string)
• Make resolve depend on verify-version in release workflow for fail-fast behavior
• Simplify build-and-release needs to [test] (transitive deps cover the rest)

Addresses Copilot review feedback from #173.

Test plan

• CI passes with correct cache keys
• Release workflow fails fast if version mismatch is detected

[Copilot]

Pull request overview

Updates CI/release GitHub Actions workflows to make SwiftPM caching effective and to adjust the release job dependency graph for earlier failure on version mismatches.

Changes:

• Update SwiftPM cache keys to hash Package.swift (instead of gitignored Package.resolved).
• Make resolve depend on verify-version in the release workflow for fail-fast behavior.
• Simplify build-and-release job dependencies to only require test (relying on transitive needs).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
.github/workflows/release.yml	Adjust release job dependency chain and update SwiftPM cache keys to use Package.swift.
.github/workflows/pr-checks.yml	Update SwiftPM cache keys to use Package.swift for PR checks jobs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Same cache-key immutability concern here: once this Package.swift-based key exists, subsequent workflow runs cannot update the cache contents under that key. Consider using a unique suffix for the primary key and a restore-keys prefix scoped to the Package.swift hash so restored dependencies don’t get stuck indefinitely.

[Copilot]

The cache key is now stable across runs (based only on Package.swift), but because cache entries are immutable per key, this can prevent refreshing dependencies over time. Consider using a unique per-run primary key (while restoring from a Package.swift-hash prefix) so the cache can be updated as dependency resolutions change.

[Copilot]

Same cache-key immutability issue: once a cache exists for this Package.swift-based key, it can’t be overwritten by later runs, which can lock in stale dependency checkouts. Prefer a unique primary key with restore-keys scoped to the Package.swift hash to allow periodic refresh.

[Copilot]

Same cache-key immutability concern: a stable Package.swift-only key means the cache cannot be refreshed once created. Consider switching to a unique per-run key with a restore-keys prefix that includes the Package.swift hash (and optionally a broader OS-only fallback) to keep caches current.

[Copilot]

The cache key is now stable across runs (based only on Package.swift), but GitHub Actions caches are immutable per key; once this key exists, future runs won’t be able to refresh dependencies under the same key. Consider adding a unique suffix (e.g., run ID) to the primary key and tightening restore-keys to a Package.swift-scoped prefix so the cache can be updated over time without restoring unrelated caches.

[Copilot]

Same cache-key immutability concern here: with a key derived only from Package.swift, the cache can become permanently stale because actions/cache won’t overwrite an existing key. Use a unique per-run primary key with a restore-keys prefix that includes the Package.swift hash to allow refreshes while keeping good hit rates.