2026.10.16.2: bundle xlings 2026.10.16.2 (mcpp inside a Luban system uses the system's gcc)

[Sunrisepeak]

Summary

• Bundle xlings 2026.10.16.2 (2026.10.16.2: a home inside a Luban system builds its catalog; the host's userland as the host has it; editions an older client can use openxlings/xlings#677). Inside a Luban system mcpp build uses the system's gcc.
• Before this, the registry could not build its catalog there: its recipe worker needed bwrap, which cannot start inside a system. The registry was also layered on the system's home in addition to its upstream, so the borrowed toolchain had no entry in the store mcpp reads. The build stopped at Bootstrap patchelf/ninja ... did not complete.
• xlings 2026.10.16.2 fences that worker with Landlock inside a system, and gives a home that names upstreams no system layer. xim-pkgindex#987 makes the gcc recipe keep a borrowed payload's specs.
• CI and release pins move to xlings 2026.10.16.2. mcpp is 2026.10.16.2, with a CHANGELOG entry.
• pin_runtime is kept. It is idempotent, and xlings 2026.10.16.2 now also refreshes the runtime links when a runtime is installed.

Test

• Locally, inside a Luban core system (sandbox carrier) with xlings 2026.10.16.2 as the registry's xlings and xim-pkgindex#987, mcpp new && mcpp build && mcpp run builds and runs.
• The registry's xim-x-gcc/16.1.0 is a link to /xlings/data/xpkgs/xim-x-gcc/16.1.0, and no toolchain is downloaded.
• After this release, xim-pkgindex#986's editions CI runs the same check in a fresh core system.

Co-authored-by: speak-agent 248744407+speak-agent@users.noreply.github.com