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

## 补上 main 已有那条注释的根因

`main` 已经因为 `xim:libglvnd@>=1.7.0.1` 装不上而把 pin 抬到 `2026.8.10.1`,
方向是对的。补一句根因:**这不是索引的数据缺陷,是内带 xlings 的版本。**

四段版本参与范围比较由 xlings `2026.8.9.2` 修好(N 段 semver 重写;
fontconfig `2.15.0.1` 撞过同一个洞)。`2026.8.8.2` 内带的是 `2026.8.8.1`,
正好落在修复之前 —— 所以它把一个**存在**的包报成 `not found`:

    xlings reported: E_INVALID_INPUT: package 'xim:libglvnd@>=1.7.0.1' not found

用发布出去的载荷实测:

    $ mcpp-2026.8.10.2-linux-x86_64/registry/bin/xlings info "xim:libglvnd@>=1.7.0.1"
      selected version: 1.7.0.1

**`xim-pkgindex` 一个字都不用改。**

## 为什么取 `.3` 而不是 `.1`

它另外带两个直接影响本仓的修复:

- **mcpp#405** 依赖 BMI 缓存命中时,被恢复的包传递依赖的 `std` 没进构建图 ——
  **每个图形项目的第二次构建必挂**(消费方自己不 `import std` 时现形,
  imgui 模板生成的 `main.cpp` 恰好如此)。
- **mcpp#407** `mcpp build` 会重放 `mcpp test` 留下的构建图。

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

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

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

> 「main 是绿的」和「这些包装得上」是两个不同的断言。

`sweep-alert` 把第二个变成一条有人看得见的 issue:**单条 issue 反复 reopen + 追评**,
不是每周开一个新的(每周开新 issue 的追踪器是会被静音的追踪器)。只对
`schedule` / `workflow_dispatch` 生效 —— PR 的失败在 PR 上已经看得见。
查询两个分支都实测过:标题不存在时返回空(走创建),存在时能正确取到编号(走追评)。

## 本次全量扫描结果

12 个 workspace shard 全绿。**8 个图形成员由 FAIL 转 ok**:

    gui-stack            130s  ok      (上次  43s FAIL)
    imgui-window          88s  ok      (上次  23s FAIL)
    eui-neo              161s  ok
    eui-neo-app-main     123s  ok
    eui-neo-markdown     128s  ok
    eui-neo-sdl2         603s  ok
    eui-neo-vulkan       144s  ok
    eui-neo-window       133s  ok

耗时本身就是证据:上次是**失败得快**,这次是**真的在构建**。
`graphics install: no side effects` 也一并转绿(它红在同一句话上)。

Author: Sunrisepeak

.github/workflows/validate.yml

@@ -152,9 +152,18 @@ env:
   # 2026.8.10.1 又加了一层:2026.8.8.2 的 registry 无法解析
   # `xim:libglvnd@>=1.7.0.1` —— compat.glx-runtime@2026.08.08 在 linux 上的硬依赖,
   # 任何经 compat.glfw 的 X11 profile 触及图形栈的包(eui-neo 等)都会踩到,导致
-  # linux 上安装即失败(main 的 graphics 检查因此持续变红)。2026.8.10.1 的 registry
-  # 带上了 libglvnd;glibc 修复(2026.8.8.2)依然被满足。
-  MCPP_VERSION: "2026.8.10.1"
+  # linux 上安装即失败(main 的 graphics 检查因此持续变红)。
+  #
+  # 补充根因:这不是索引的数据缺陷,是**内带 xlings 的版本**。四段版本参与范围比较
+  # 由 xlings `2026.8.9.2` 修好(N 段 semver 重写);mcpp `2026.8.8.2` 内带的是
+  # `2026.8.8.1`,正好落在修复之前,所以它把一个存在的包报成 `not found`。
+  # `2026.8.10.1` 起内带的 xlings 已含该修复。**`xim-pkgindex` 一个字都不用改。**
+  #
+  # 取 `2026.8.10.3` 而不是 `.1`,是因为它另外带两个直接影响本仓的修复:
+  #   - mcpp#405 依赖 BMI 缓存命中时,被恢复的包传递依赖的 `std` 没进构建图 ——
+  #     **每个图形项目的第二次构建必挂**(消费方自己不 `import std` 时现形)。
+  #   - mcpp#407 `mcpp build` 会重放 `mcpp test` 留下的构建图。
+  MCPP_VERSION: "2026.8.10.3"
 
 jobs:
   lint:
@@ -1131,3 +1140,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