[On1x]

#208 stopped the production job from taking an exact hit on the testnet cache. It also removed the general restore-key from the testnet job, and that left the testnet build with no source of dependency objects at all: its own prefix started empty, and the ~170 chain objects it saves per run (29–58 MiB) never contain the ones the shared cache holds (190–250 MiB).

Measured on master, nothing else changed

run	commit	testnet job	ccache
41094491455	29110a28 (before #208)	2m53s	2730 / 3112 hits (87.7 %)
41094636291	bf5389e8 (first run on the new key)	13m07s	0 / 174 hits (0 %)
41099741454	4bbcf2d5 (second run)	14m08s	restored its own 29 MiB entry, still cold

The restore step in bf5389e8 says it plainly: Cache not found for input keys: viz-cache-mount-testnet-…-<sha>, viz-cache-mount-testnet-…-<hash>-, viz-cache-mount-testnet-…-main- — every key is testnet-scoped, and no testnet entry existed yet. The second run does restore a testnet entry, but by then it only holds what that run compiled itself, so it stays at 14 minutes. It does not heal.

What the change does

Adds the shared prefix as the last restore-key of the testnet job:

restore-keys: |
  viz-cache-mount-testnet-${{ runner.os }}-main-${{ hashFiles('share/vizd/docker/Dockerfile-testnet') }}-
  viz-cache-mount-testnet-${{ runner.os }}-main-
  viz-cache-mount-${{ runner.os }}-main-

Reading is safe and does not undo #208:

• saving still goes to the viz-cache-mount-testnet-… key, so production can never exact-hit it again — the bug ci: give the testnet image its own ccache on master #208 fixed stays fixed;
• ccache is content-addressed, so objects compiled with different flags simply miss instead of being reused wrongly;
• the apt caches come from the same base image.

The testnet job prefers its own entries: the general prefix is listed last and only matches production keys.

Also drops the comment paragraph above the step — it still said both jobs hash both Dockerfiles and share a key prefix, which stopped being true in #208.

Verification

YAML parses and both jobs keep their intended key lists (yaml.safe_load, printed per job). The real acceptance is the first master push after the merge: the testnet job should be back near 3 minutes and its ccache report in the 75–90 % range. Until then this is an unproven prediction, not a result.