pin the installer to 2026.8.27.5, not .4

The pin request named 2026.8.27.4 on the assumption it was about to be
released. It was not: .4 shipped 2026-08-27T10:18 and .5 shipped three hours
later, so .4 is the OLDER version, and mcpp already pins .5 as
src/xlings/xlings.cppm kXlingsVersion with check_version_pins.sh enforcing it
across the repo. xim-pkgindex agrees. .5 also has a behaviour .4 lacks --
declarations beat the index during resolution -- so pinning these forks to .4
would have installed a strictly weaker xlings than the rest of the ecosystem
standardises on.

The gap the request pointed at was real, just not where it said: these two CI
workflows were not pinned AT ALL. They ran `curl … | bash` and took whatever
was newest that morning, which is why this is worth doing -- an unpinned
installer means a red run cannot be told apart from an ecosystem change.

Analysis recorded in mcpp-index
.agents/docs/2026-08-30-gbm-cross-repo-closed-loop-plan.md section 15.

Author: speak-agent

.github/workflows/ci.yml

@@ -50,7 +50,7 @@ jobs:
       - name: Install xlings + mcpp
         env:
           XLINGS_NON_INTERACTIVE: "1"
-          XLINGS_VERSION: "2026.8.27.4"
+          XLINGS_VERSION: "2026.8.27.5"
         run: |
           curl -fsSL https://d2learn.org/xlings-install.sh | bash
           echo "$HOME/.xlings/bin" >> "$GITHUB_PATH"