ci: MCPP_VERSION -> 2026.8.10.2,并让失败的全量 sweep 开 issue

## 为什么 8 个图形成员是红的

不是数据缺陷。`xim:libglvnd@>=1.7.0.1` 从 xlings 2026.8.9.2 起解析正常
(四段版本 semver 重写,fontconfig 2.15.0.1 撞过同一个洞)。红的原因是这里钉在
mcpp 2026.8.8.2 —— 它内带 xlings 2026.8.8.1,**正好落在修复之前**:

    MCPP_VENDORED_XLINGS: …/mcpp-2026.8.8.2-linux-x86_64/registry/bin/xlings
    xlings reported: E_INVALID_INPUT: package 'xim:libglvnd@>=1.7.0.1' not found

`xim-pkgindex` 一个字都不用改。本机用 xlings 2026.8.10.2 实测:

    $ xlings info "xim:libglvnd@>=1.7.0.1" --agent
      selected version: 1.7.0.1

2026.8.10.2 内带 xlings 2026.8.10.4,同时带 #405(依赖 BMI 缓存命中丢 std 边)
与 #407(普通构建重放测试图)的修复 —— 前者让每个图形项目的第二次构建必挂。

**min_mcpp / latest_mcpp 不动。** 需要新客户端的是图形成员的**安装**,
不是这个索引的**寻址**;抬全局下限会让旧客户端拿不到与图形无关的每一个包,
而索引是数据、mcpp 是程序,发布数据不得让已发布的程序失效。

## 失败的全量 sweep 现在会被看见

周更 cron 已经在跑全量,但**红了不拦任何东西、也不通知任何人**,所以跑和不跑没有区别。
实测:8 个图形成员以同一句话失败了数周,而 `main` 一直显示绿 —— 因为真正会构建它们的
`workspace` job 在每一次 push 上都是 `skipped`。

「main 是绿的」和「这些包装得上」是两个不同的断言。新增的 `sweep-alert` 把第二个
变成一条有人看得见的 issue(单条 issue 反复 reopen + 追评,不是每周开一个新的 ——
每周开新 issue 的追踪器是会被静音的追踪器)。只对 schedule / dispatch 生效:
PR 的失败在 PR 上已经看得见。

Author: Sunrisepeak

.github/workflows/validate.yml

@@ -149,7 +149,7 @@ env:
   # 用早于 2026.8.8.2 的 mcpp 重新落地这份改动,就是在仍会犯这个错的引擎上复现
   # 事故条件。tests/check_graphics_install_side_effects.sh 也需要它 —— 该测试在
   # 更旧的 mcpp 上失败是**有意的**。
-  MCPP_VERSION: "2026.8.8.2"
+  MCPP_VERSION: "2026.8.10.2"
 
 jobs:
   lint:
@@ -1126,3 +1126,57 @@ jobs:
           name: member-timings
           path: member-timings.tsv
           retention-days: 90
+
+  # ─────────────────────────────────────────────────────────────────────────
+  # A full sweep that fails must be SEEN.
+  #
+  # Selective CI is structurally unable to notice a published package that
+  # broke because something UPSTREAM changed: no PR's diff names it, so no
+  # PR selects it. The weekly cron exists for exactly that, and it already
+  # ran — but a red cron blocks nothing and pages nobody, so it may as well
+  # not have run. Measured: eight graphics members failed the same way for
+  # weeks while `main` showed green, because the job that builds them was
+  # `skipped` on every push.
+  #
+  # `main` is green and the packages install are two different claims. This
+  # job turns the second one into an issue somebody sees.
+  #
+  # Only for full sweeps (schedule / manual dispatch). A PR's failure is
+  # already visible on the PR.
+  sweep-alert:
+    name: full sweep failed — open an issue
+    needs: [workspace]
+    if: >-
+      always()
+      && needs.workspace.result == 'failure'
+      && (github.event_name == 'schedule' || github.event_name == 'workflow_dispatch')
+    runs-on: ubuntu-latest
+    permissions:
+      issues: write
+    steps:
+      - name: Open or update the sweep-failure issue
+        env:
+          GH_TOKEN: ${{ github.token }}
+          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+        run: |
+          set -euo pipefail
+          TITLE="full workspace sweep is failing"
+          # One issue, reopened and appended to — not one per run. A tracker
+          # that produces a new issue every week is a tracker people mute.
+          NUM=$(gh issue list --state all --search "$TITLE in:title" \
+                  --json number,title,state \
+                  --jq "[.[] | select(.title == \"$TITLE\")] | first | .number // empty")
+          BODY=$(printf '%s\n' \
+            "The weekly full sweep failed: $RUN_URL" \
+            "" \
+            "This is the only signal that catches a published package broken by an" \
+            "upstream change — selective CI cannot select a member no diff names." \
+            "" \
+            "Check the \`workspace\` job's failed shards for which members regressed.")
+          if [ -n "$NUM" ]; then
+            gh issue reopen "$NUM" 2>/dev/null || true
+            gh issue comment "$NUM" --body "$BODY"
+            echo "commented on #$NUM"
+          else
+            gh issue create --title "$TITLE" --body "$BODY"
+          fi