ci: bootstrap pin -> 0.0.109 (released, mirrored, indexed)

[Sunrisepeak]

ci: bootstrap pin -> 0.0.109 (released, mirrored, indexed)

0.0.109 is on both mirrors byte-for-byte identical to the GitHub release,
xim-pkgindex#418 is merged, and a clean XLINGS_HOME resolves and installs it:

xlings install mcpp@0.0.109 -y -g   ->  mcpp 0.0.109 (bundled xlings 0.4.69)
bare `eigen = "5.0.1"` dependency    ->  builds, runs, prints 10

That last line is the acceptance test for what 0.0.109 fixes: a bare-name
dependency served by a compat descriptor now addresses as compat:eigen
rather than the mcpplibs:eigen no index is keyed by.

Also bumps ci-fresh-install.yml's MCPP_PIN, which its own comment says to move
with this pin and which had been left five releases behind at 0.0.103 — so the
workflow that exists to verify "what a user's fresh install resolves" was
verifying a version nobody installs.

The plan doc picks up the six problems found during release ops that are NOT
fixed here, so they do not live only in a chat log:

F1 the sandbox xlings is vendored once at self init and never refreshed,
so an upgraded-in-place install keeps whatever xlings it started with —
and that copy, not the system one, resolves dependencies. Post-migration
that means one arbitrary package "not found", differing per machine.
Fresh installs are safe (the tarball ships 0.4.69). Diagnose, do not
silently rewrite a user's sandbox.
F2 gtc prints access_token in cleartext on upload failure.
F3 gtc's exit code lies on the obs_callback path — the macOS asset reported
failure and was in fact serving correctly. Verify by GET, not exit code.
F4 the 180s per-asset gitcode cap did not degrade, it collapsed: all four
tarballs timed out, including a 3.9MB one.
F5 index artifacts lag git. raw.githubusercontent and the pointer JSON both
showed 0.0.109 while clients still resolved the previous artifact.
Polling raw is a misleading readiness signal.
F6 the index URL is spelled two different ways across the repo.