Cache --only / --only-suffix runs under a rule-scoped key

[SanderMuller]

Why

#8029 fixed --only / --only-suffix runs poisoning the full-run cache by not caching them at all.
As @samsonasik noted #8029 (comment), that removed the cache on repeated selective runs, and #7641 tried to bring it back but hit cache thrash.

This scopes the per-file cache key by the active rule selection, so selective and full runs use
separate, coexisting cache entries:

• a repeated --only X is served from cache again;
• a full run is never poisoned by a selective run, Fix --only runs caching files as unchanged, hiding pending changes from full runs #8029's fix stays intact;
• nothing is cleared on a mode switch, so no back-and-forth thrash.

A full run keys exactly as before, existing caches aren't invalidated and
full-run behaviour is unchanged. That also makes it trivially revertable.

Verify

The existing clean-file caching test is unchanged (full-run caching still works). A new test covers the selective case: after an --only run the file is cached under its own scope (a repeat --only is served from cache), while a full run treats it as changed, so a pending change can't be masked. Checked in parallel too.

Warm repeated --only on rector's own rules/ (~790 files, one rule): ~14s reprocess on main →
~0.3s served from cache. That's the warm-repeat best case — the win is skipping the reprocess on repeats.

[SanderMuller]

Benchmark for the repeated --only case this restores — hyperfine, 5 runs after a warmup, on this repo's own rules/ (790 files), sequential, --dry-run, a single rule:

• main: 15.50 s ± 0.43 s — no --only cache, so every run reprocesses
• this branch: 0.45 s ± 0.03 s — served from the scoped cache

~34× on the warm repeat. Cold/first runs are unchanged, and full runs key exactly as before, so existing caches aren't touched — the gain is purely the avoided reprocess on repeated selective runs.