fix(ci): the registry cache must not carry the resolved index

`actions/cache` held all of `~/.mcpp/registry`, and that includes
`data/xim-pkgindex` and `data/mcpplibs` — the RESOLVED indices, the
descriptors mcpp actually reads. The key's `restore-keys` prefix ends at
MCPP_VERSION, so a run restored whatever index the previous run left
behind, regardless of what had landed upstream in between.

THIS ALREADY COST A DAY

Two successive fixes to `xim:wix` (openxlings/xim-pkgindex#808, then #809)
were each merged, each re-run here, and each appeared to change nothing.
Both were read as "the fix does not work" and the second one was written
on that false premise. Neither had ever been loaded.

The tell was in the logs the whole time: `7zip`, which #809 declares as a
dependency, appeared ZERO times in a run that was supposedly testing #809.
A fix that is not in the log is not being tested.

What eventually refreshed the index was moving MCPP_VERSION for unrelated
reasons — a coincidence of cache-key composition, not a mechanism anyone
chose. Until then the rule was, in effect: **a change to a xim package
cannot be verified from this repo's CI.**

EXCLUDE, DO NOT KEY ON IT

Adding the index revision to the key would evict everything on every
upstream commit. Measured on a developer machine: the two index trees are
~8 MB, `data/xpkgs` is ~28 GB. Re-fetching 8 MB per job is the cheap half
and it is the half that has to be current; rebuilding 28 GB because a
descriptor changed in another repository is the expensive half and it does
not.

So the payloads and toolchains stay cached and the indices stop being.

Author: Sunrisepeak

.github/workflows/validate.yml

@@ -972,7 +972,32 @@ jobs:
         with:
           # Holds toolchains AND the built compat packages (data/xpkgs), so a
           # repeat `mcpp test` rebuilds little.
-          path: ~/.mcpp/registry
+          #
+          # THE INDEX TREES ARE EXCLUDED, and that exclusion is the whole point
+          # of this entry's shape. `data/xim-pkgindex` and `data/mcpplibs` are
+          # the RESOLVED indices -- the descriptors mcpp reads. Caching them
+          # under a key whose `restore-keys` prefix ends at MCPP_VERSION means
+          # a run restores whatever index the last run happened to leave, no
+          # matter what landed upstream since.
+          #
+          # That is not hypothetical. Two successive fixes to `xim:wix`
+          # (openxlings/xim-pkgindex#808, then #809) were each merged, each
+          # re-run here, and each appeared to change nothing -- because neither
+          # was ever loaded. The tell was that `7zip`, which #809 declares,
+          # appeared ZERO times in a log that was supposedly testing #809. The
+          # only thing that ever refreshed the index was moving MCPP_VERSION,
+          # which is a coincidence of cache-key composition rather than a
+          # mechanism anyone chose.
+          #
+          # Excluding rather than keying on the index revision is deliberate.
+          # Keying would evict everything on every upstream commit; measured on
+          # a developer machine, the index trees are ~8 MB against ~28 GB of
+          # `data/xpkgs`. Re-fetching 8 MB per job is the cheap half, and it is
+          # the half that has to be current.
+          path: |
+            ~/.mcpp/registry
+            !~/.mcpp/registry/data/xim-pkgindex
+            !~/.mcpp/registry/data/mcpplibs
           key: ${{ env.REGISTRY_CACHE_KEY }}
           restore-keys: |
             mcpp-registry-${{ runner.os }}-${{ matrix.toolchain }}-${{ env.MCPP_VERSION }}-