cache trim/janitor: entries keyed by cache key collapse across refs (can target the wrong id) #137

Found in M2-41 (kernal-api #93) at ci.yml@78506e7.

ci_lint.cache.ops.trim and janitor build by_key = {c.entry.key: c for c in classified}, and _findings_to_plan resolves each finding through path = "cache:<key>". GitHub cache keys are unique per ref, not per repository. The same key can live on refs/heads/main and on refs/pull/N/merge at the same time, so these entries collapse:

• kernal-api had 6 setup-uv entries on merged PR meta: CACHE-034 remediation burn-down -- every pre-prune waiver honoured or dropped, fleet audit to zero #360's merge ref. 4 of them share their exact key with a live main entry. cache audit reports all 6 as CACHE-008, but a janitor dry run plans only 2 of them (the two whose key is unique to the PR ref).
• Worse, for a shared key by_key[key] can resolve to the main entry's id. trim would then delete the default-branch entry instead of the closed PR's.

Fix: key findings and plans by cache id, not by key. Findings could carry the id, e.g. cache:<id>:<key>, or the audit could pass ids through. Add a fixture with one key on two refs.

Workaround used in kernal-api: ci-lint cache heal --key K --ref refs/pull/360/merge for the 4 shared-key entries.