ci: cache the DLoad version registry between workflow runs

[roxblnfk]

🔍 What was changed

• The test matrix restores DLoad's version registry from a GitHub cache before composer get:binaries, and points DLoad at it through DLOAD_CACHE_DIR.
• Only the suites that pass download-binaries: true carry the step; unit jobs are untouched.

Why?

Four of the five suites download binaries, which is 68 jobs per workflow run asking the GitHub API for release metadata. The restored registry keeps those calls off the rate limit, and serves the stored releases when a check fails anyway.

Review notes

The cache key looks like it can never hit, and that is deliberate: a cache entry is immutable, so github.run_id keeps the key missing and lets every job save its own registry, while restore-keys: dload-registry- reads the newest one any previous run left behind. inputs.test-command and strategy.job-index are in the key so the 68 parallel jobs do not race for a single entry — without them all but one job fails to save.

Checklist

• How was this tested:
  • Not run yet — the workflow has to land on a branch before the cache step can be observed