0.4.13

release: 0.4.13 — fix(elfpatch): patchelf op order workaround (#257)

* release: 0.4.13 — fix(elfpatch): patchelf op order workaround

Bumps VERSION 0.4.12 → 0.4.13 + add_requires("mcpplibs-xpkg 0.0.37").

Hotfix for a patchelf 0.18.0 corruption bug that surfaced production-
wide after xim-pkgindex#108 declared `runtime = { glibc, gcc }` deps
on five common prebuilt packages (cmake, mdbook, ninja, node, xmake).
Predicate-driven elfpatch then fired on these binaries; for compact
ELFs (~≤ 280 KB, e.g. ninja 1.12.1 at 273 KB) patchelf 0.18.0 has an
order-sensitive corruption bug: --set-interpreter before --set-rpath
shifts the dynamic section so the subsequent rpath op writes through
DT_NEEDED, segfaulting the binary at execve+1 with no recovery.

mcpplibs-xpkg v0.0.37 reverses the op order in
_patch_elf_executables and _patch_elf fallback so --set-rpath runs
first. Linux-only fix; macOS / Windows unaffected (different
toolchains, no equivalent issue).

Symptom on 0.4.12:
    $ xlings install ninja
    $ ninja --version
    Segmentation fault (core dumped)
    # OR
    $ cmake ...                    # cmake driving small build tools
    failed(-1) — child process killed by signal

Symptom on 0.4.13 (verified locally with isolated XLINGS_HOME):
    $ xlings install ninja
    elfpatch._apply: source=predicate:single
    ninja: elfpatch auto: 1 1 0
    $ ninja --version
    1.12.1
    INTERP=…/xim-x-glibc/2.39/lib64/ld-linux-x86-64.so.2
    RUNPATH=…/xim-x-glibc/lib64:…/xim-x-gcc/lib64:…/subos/default/lib

Migration: 0.4.12 → 0.4.13 is binary-compatible. The in-place
self-update path (xself install / quick_install) handles the upgrade.
After upgrade, packages affected by xim-pkgindex#108 (cmake / mdbook /
ninja / node / xmake) need a re-install via `xlings uninstall <pkg> &&
xlings install <pkg>` to rebuild the corrupted payload — `xlings
install` alone won't re-patch already-installed payloads (correct
"installed payload is sacred" behavior, see installer.cppm:1080).
For the auto-recovery path (broken payload silently re-patched on
next install), see TODO in upstream tracking.

Verified locally:
  - libxpkg unit tests 27/27 pass (post-fix, includes new
    ApplyElfpatchAuto_LinuxRpathBeforeInterpreter regression test)
  - E2E in isolated XLINGS_HOME: ninja install with new predicate +
    new order produces a working binary, INTERP / RUNPATH correctly
    set, `ninja --version` exits 0

libxpkg PR: https://github.com/openxlings/libxpkg/pull/13 (merged, v0.0.37)
Analysis: docs/plans/2026-05-03-patchelf-order-bug-analysis.md (in libxpkg)
mcpplibs-index: mcpplibs/mcpplibs-index@bc4f740 registers v0.0.37

* ci: retrigger after xim-pkgindex#110 merge

* ci: retrigger after xim-pkgindex#111 (comprehensive namespace deps)

* ci: pin XIM_PKGINDEX_REF to stable commit (pre-#108) for fixture clone

The xlings E2E test fixture is dynamically cloned from xim-pkgindex
main at CI time. xim-pkgindex#108 (declare runtime deps on
cmake/mdbook/ninja/node/xmake) introduced bare-name deps that cascade
into ambiguity errors in E2E-05's dual-mount scenario, plus exposed
latent issues (gcc-specs-config not auto-activated, node not finding
libstdc++ at runtime).

Pin XIM_PKGINDEX_REF to commit 9cb6982 (PR #106 merge — last commit
before #108) until those cascading issues stabilize. This restores the
previously-passing E2E green state and decouples xlings's release CI
from in-flight xim-pkgindex churn.

Bump after xim-pkgindex deps stabilize: namespace prefixes universal
(continuation of #110/#111), runtime lib closure verified (gcc's
lib64 actually reaches consumers' RPATH), and gcc-specs-config
activation pathway sorted out.

Applied to all four workflows that clone the fixture: xlings-ci-linux,
xlings-ci-macos, xlings-ci-windows, release.

* ci: support commit-SHA refs in prepare_fixture_index.sh

`git clone --branch` only accepts branch/tag names, not SHAs. When
XIM_PKGINDEX_REF is set to a commit SHA (40-char hex), do a full clone
then `git checkout <sha>`. Branch/tag refs continue to use the depth-1
shallow clone path.

* ci: pin XIM_PKGINDEX_REF to stable commit (pre-#108) for fixture clone

Bind XIM_PKGINDEX_REF time-matched with BOOTSTRAP_XLINGS_VERSION=v0.4.8
(xlings released 2026-04-30 18:25 UTC, this commit lands 2026-04-30
17:43 UTC — last xim-pkgindex commit before 0.4.8 went live, so the
schema/conventions match what 0.4.8 expects).

Decouples xlings CI from in-flight xim-pkgindex churn (post #107: bare-
name deps + new runtime-dep declarations on prebuilts cascading into
E2E-05's dual-mount scenario). Bump in lockstep with BOOTSTRAP_XLINGS
once both stabilize.

Applied to all four workflows that clone the fixture: xlings-ci-linux,
xlings-ci-macos, xlings-ci-windows, release.

* ci: use full 40-char SHA for XIM_PKGINDEX_REF (regex match)