[linyiru]

Job identity and cache scope used the repository's owner/name. That name passes to a different repository once its first owner renames or deletes it. A repository later created under the same name, and served by the same cache, could then read the earlier repository's retained entries, git packs included, through an empty restore prefix and without knowing any key.

Changes:

• Resolution reads GitHub's repository ID from GET /repos/{name}. The workflow run must report the same ID, or resolution fails.
• Identity.RepositoryID is required by Validate.
• The cache server scopes entries by Identity.ScopeKey(), which is <lowercased name>#<id>. Keeping the name in the key also means a repository transferred to another owner does not carry caches built there into its new owner.
• Entries saved under the name alone match no identity and age out. The first jobs after an upgrade, and a repository's first jobs after a rename or transfer, miss the cache once. Daemon restarts clear identity records, so only a cache-server newer than its daemon denies, until both are upgraded.

Tests:

• Resolution carries the ID, and fails without it or on a mismatch.
• A recreated repository reads nothing of its predecessor's.
• An index saved by the previous version is not restored.
• Validate requires the ID.
• scripts/mutate.sh confirmed that the scope key, the required run ID and the Validate check are each caught by a test.

Review: a fresh reviewer agent reviewed the change. It confirmed that the only identity that grants access comes from Registry.Start through GitHub.Resolve, that an old name cannot resolve to a renamed repository's ID, and that nothing builds a URL from the rewritten field. Its should-fixes are fixed here: the run's ID is now required, and the upgrade path has a test.