the measurement can run against an engine that has not been released (#452)

* the measurement can run against an engine that has not been released

Every ecosystem repository mcpp's changes reach already honours
`MCPP_SOURCE_REF`: non-empty, it builds the engine from that ref and asserts
that the binary on PATH is the one it built. This workflow was the gap, and it
is the one that matters most --- mcpp's own CI cannot see a defect that appears
only in a real dependency graph, and this repository holds thirty of them.

THE COST OF THE GAP IS MEASURED, NOT HYPOTHETICAL. 2026.9.20.1 shipped on
2026-09-20. Within a day the four members that stop at `#include <windows.h>`
through a borrowed `__CYGWIN__` --- archive, sqlite3, mimalloc, c-ares ---
made a second release necessary. That reading was available from these same
thirty graphs before the first release merged; nothing could produce it,
because this job could only install a published engine.

A release is not one build. It is a tag, four platform builds, two mirrors,
a GET check per asset, an xim-pkgindex bump, an index artifact, and a
consumer-side confirmation. What this closes is a second pass down that whole
chain.

Shape: the released engine the pin names is still installed, because mcpp
builds itself and is its own bootstrap; the build from the ref then replaces it
on PATH, and `MCPP_HOME` follows it. `.xlings.json` is removed from the clone
first --- it pins the mcpp that compiles mcpp, does not move when mcpp is
released, and would otherwise ask the index for a version it may no longer
carry. The version under review is printed, because a PATH entry that does not
win looks exactly like one that does until something has been measured with
the wrong engine.

The pins-agree check is unaffected: it compares this workflow's pin with
pins.toml, and both still name the released version. A source ref is an
override on top of that agreement, not a replacement for it.

* the engine under review replaces the released binary in place

The first revision prepended the freshly built `mcpp` to PATH beside its own
`target/` directory. The measurement then stopped at

    error: xlings binary not found

A released archive carries a BUNDLED xlings that mcpp resolves relative to its
own location; a binary sitting in a build tree has no such neighbour, and
moving `MCPP_HOME` to that tree moved the search with it.

Overwriting `bin/mcpp` inside the released root instead keeps everything about
that root as the release left it --- the bundled xlings, the layout,
`MCPP_HOME`, the PATH entry already exported --- and changes only the one file
under review. The version is reported from the path the measurement will
actually run, because a copy that did not land looks exactly like one that did
until something has been measured with the wrong engine.

Found by using this mechanism on its first real cross-verification, which is
where a plumbing defect is cheap.

Author: Sunrisepeak

.github/workflows/openkal-compat.yml

@@ -17,6 +17,10 @@ on:
         description: "Space-separated members to measure (empty = every listed member)"
         required: false
         default: ""
+      mcpp_ref:
+        description: "Branch of mcpp-community/mcpp to build and measure against (empty = the released pin)"
+        required: false
+        default: ""
   pull_request:
     paths:
       - "pkgs/**/*.lua"
@@ -34,6 +38,22 @@ env:
   # pins.toml for why this pin, not just validate.yml's, is gated by the
   # index floor.
   MCPP_VERSION: "2026.9.20.1"
+  # CROSS-VALIDATION BEFORE A RELEASE, NOT AFTER IT.
+  #
+  # Empty in an ordinary run, so this measurement keeps using the RELEASED
+  # engine the pin above names. Set it -- workflow_dispatch input, or the
+  # repository variable -- and the same measurement runs against mcpp built
+  # from that ref instead.
+  #
+  # THIS EXISTS BECAUSE AN ENGINE CHANGE'S REAL LOAD IS HERE. mcpp's own CI
+  # cannot see a defect that appears only in a real dependency graph; this
+  # repository holds thirty such graphs and could not see the engine until it
+  # had been published. 2026.9.20.1 shipped and, within a day, the four
+  # members that stop at `windows.h` through a borrowed `__CYGWIN__` made a
+  # second release necessary -- a reading this job could have produced before
+  # the first one merged. Every ecosystem repository that mcpp's changes reach
+  # already honours this variable; this workflow was the gap.
+  MCPP_SOURCE_REF: ${{ github.event.inputs.mcpp_ref || vars.MCPP_SOURCE_REF }}
   XLINGS_NON_INTERACTIVE: "1"
 
 jobs:
@@ -76,6 +96,44 @@ jobs:
           echo "$root/bin" >> "$GITHUB_PATH"
           echo "MCPP_HOME=$root" >> "$GITHUB_ENV"
 
+          # The released engine above is the BOOTSTRAP when a ref is under
+          # review: mcpp builds itself and there is no other compiler for it
+          # here.
+          #
+          # THE BUILD REPLACES THE BINARY INSIDE THE RELEASED ROOT, rather than
+          # being prepended to PATH beside its own `target/` directory. An
+          # earlier revision did the latter and the measurement stopped at
+          #
+          #     error: xlings binary not found
+          #
+          # because a released archive carries a BUNDLED xlings that mcpp
+          # resolves relative to its own location, and a freshly built binary
+          # has no such neighbour. Overwriting `bin/mcpp` in place keeps that
+          # root --- its bundled xlings, its layout, `MCPP_HOME`, the PATH
+          # entry already exported above --- exactly as the released engine
+          # left it, and changes only the one file under review.
+          if [ -n "${MCPP_SOURCE_REF:-}" ]; then
+            src="$RUNNER_TEMP/mcpp-src"
+            git clone --quiet --depth 1 --branch "$MCPP_SOURCE_REF" \
+              https://github.com/mcpp-community/mcpp.git "$src"
+            # `.xlings.json` at mcpp's root pins the mcpp that compiles mcpp,
+            # and that pin does not move when mcpp is released, so a build
+            # inside the checkout would try to install a version the index may
+            # no longer carry. What is wanted is the source compiled by the
+            # engine installed above, which removing the file leaves.
+            rm -f "$src/.xlings.json"
+            ( cd "$src" && "$root/bin/mcpp" build --release )
+            built=$(find "$src/target" -type f -name mcpp | head -1)
+            [ -n "$built" ] \
+              || { echo "::error::mcpp did not build from $MCPP_SOURCE_REF"; exit 1; }
+            cp "$built" "$root/bin/mcpp"
+            # Reported from the path the measurement will actually run, not
+            # from the build directory: a copy that did not land looks exactly
+            # like one that did until something has been measured with the
+            # wrong engine.
+            echo "under review: $("$root/bin/mcpp" --version)  (from $MCPP_SOURCE_REF)"
+          fi
+
       # The Windows cross headers of the host are installed deliberately. A
       # graph that reached them would build differently with them present, so a
       # result that is the same here and on a runner without them is evidence