ci(cross-build): xlings 0.4.61 (root cause was broken xlings-res assets, now fixed)

The real root cause of the cross-build bootstrap failures was NOT the xlings
version or the profile code: the xlings-res/mcpp 0.0.75 GitHub release assets
were uploaded in a BROKEN state during a flaky network (asset records present
but blobs missing -> HTTP 404 on download). cross-build uses --mirror GLOBAL
(GitHub), so its 'xlings install mcpp@0.0.75' 404'd; the downstream symptom on
0.4.30 was 'version 0.0.75 not found'. GitCode assets were fine all along.

Re-uploaded all 4 GitHub xlings-res/mcpp 0.0.75 assets clean (verified GET 200 +
correct sizes). With downloads working, use 0.4.61 (current) + keep the
.xlings-index-cache.json marker-clear (forces index re-sync past a stale TTL
marker on warm caches).

Author: Sunrisepeak

.github/workflows/cross-build-test.yml

@@ -87,11 +87,12 @@ jobs:
       - name: Bootstrap mcpp via xlings
         env:
           XLINGS_NON_INTERACTIVE: '1'
-          # Stay on 0.4.30: its XLINGS_RES download resolution matches the
-          # xlings-res/mcpp release asset layout (newer 0.4.61 changed it and
-          # 404s on the mcpp artifact). The real bug was a stale INDEX, not the
-          # version — fixed by the marker-clear below.
-          XLINGS_VERSION: '0.4.30'
+          # 0.4.61 (current). The earlier 0.4.61 "download 404 for mcpp@<pin>" was
+          # NOT a version bug — the xlings-res/mcpp GitHub release assets were
+          # uploaded in a broken state (records present, blobs missing → 404 on
+          # GET); re-uploaded clean. The stale-INDEX half is handled by the
+          # marker-clear below.
+          XLINGS_VERSION: '0.4.61'
         run: |
           tarball="xlings-${XLINGS_VERSION}-linux-x86_64.tar.gz"
           curl -fsSL -o "/tmp/${tarball}" \