ci(release): 发布工作流加显式 run-name，Actions 列表不再显示提交信息（M268）

release.yml / release-guard.yml 之前没有 run-name，GitHub 默认拿提交信息当运行名，
于是 v0.2.4 那条把「孤儿提交 / 无父 / 树 = dev <hash>」这类快照模型术语贴到了公开界面。

- release.yml: tag push / tag ref dispatch => `Release v0.2.4`；分支 ref dispatch => `Release 试跑 main（分支 ref，不发布）`
- release-guard.yml: push main / dispatch => `Release guard · main`；PR => `Release guard · PR #123`
- release-publish.yml: workflow_call 不产生自己的 run，故不加（文件头写明理由）
- 只新增 run-name，所有已有 `name:` 一字未动
- packaging/docs/artifacts-and-version.md 新增 §2.1：里程碑快照提交信息只写版本 + 一句话，附正/反例

packaging/README.md

@@ -13,7 +13,7 @@
 | 节 | 主题 | 承载文件 |
 |----|------|---------|
 | §1 | 产物矩阵 | `packaging/docs/artifacts-and-version.md` |
-| §2 | 版本来源（唯一真相源） | `packaging/docs/artifacts-and-version.md` |
+| §2 | 版本来源（唯一真相源）；§2.1 里程碑快照**提交信息**怎么写（M268） | `packaging/docs/artifacts-and-version.md` |
 | §3 | 怎么构建（本地 / CI） | `packaging/docs/build-and-ci.md` |
 | §4 | 每平台运行时依赖 | `packaging/docs/runtime-deps.md` |
 | §5 | 软渲染兜底 | `packaging/docs/runtime-deps.md` |

packaging/docs/artifacts-and-version.md

@@ -51,3 +51,50 @@
 - `ull --version` 必报同一版本（脚本打包前跑一次冒烟 `ull --version` 断言版本串在其中），
   这是 `env!("CARGO_PKG_VERSION")` 的实际输出，不是估算。
 - 发布流程：先改 `Cargo.toml` 版本 + 提交 → `git tag v<ver>` → 推送 tag 触发流水线。
+
+### 2.1 里程碑快照的提交信息该长什么样（M268）
+
+发布提交的信息**会出现在公开界面上**（commit 列表、PR、`git log`，以及——没有 `run-name` 时——Actions 的运行名），
+所以它是对外文案，不是内部工作记录。
+
+默认行为（GitHub 文档原文）：`run-name` 省略或只有空白时，运行名取「事件相关的信息」，push / pull_request 触发的
+run 就是**提交信息原文**（PR 则是 PR 标题）。M268 之前 `.github/workflows/` 里 `run-name` 零命中，于是 v0.2.4 那一条的
+标题直接是提交信息：「release: v0.2.4 里程碑快照（孤儿提交，无父；树 = dev 68362e5）」——D41 快照模型的实现术语
+（无父提交、树取自 dev）泄漏到了任何人点开仓库就能看到的地方。v0.2.1~v0.2.3 那几条看着正常，只是因为那几次的
+提交信息本身干净，不是因为流水线做了什么。
+
+现在的兜底：`release.yml` 与 `release-guard.yml` 都加了显式 `run-name`（`Release v0.2.4` / `Release guard · main`），
+发布相关的 run 名不再由提交信息决定。`release-publish.yml` / `release-build.yml` 是 `workflow_call` 可复用工作流，
+**不产生自己的 run**，所以那里不加（理由写在该文件头部注释里）。**但提交信息本身照样公开可见，规矩照旧要守。**
+
+规矩只有两条：
+
+1. **版本 + 一句话**，例如 `release: v0.2.4`。想交代一句就写对外的话：
+   `release: v0.2.4（首个带 Linux 产物的稳定版）`。
+2. **不许写实现细节**：「孤儿提交」「无父」「树 = dev <hash>」「squash 了哪几个提交」这类快照模型的内部术语一个都不要。
+   过程写进 `DevDocs/` 或 PR 描述，不写提交信息。
+
+正面例子（就这样写）：
+
+```text
+release: v0.2.4
+```
+
+反面例子（真实发生过，就是泄漏到 Actions 列表的那一条）：
+
+```text
+release: v0.2.4 里程碑快照（孤儿提交，无父；树 = dev 68362e5）
+```
+
+问题不在长度，在于这段话讲的是**我们怎么做的快照**（无父提交、树取自 dev 68362e5），跟用户无关，还暴露了内部模型。
+
+**抓得住什么 / 抓不住什么**：
+
+- 抓得住（只有这两条）：加了 `run-name` 的两个工作流——`Release`（= `release.yml`）与 `Release guard`——的运行名不再
+  由提交信息决定，Actions 列表里固定是 `Release v0.2.4` / `Release guard · main` 这类人读名字。下次谁把提交信息写成
+  内部术语，**这两行不会显示它**。（已发生的那条 v0.2.4 不会追溯改名：历史 run 名是快照。）
+- 抓不住（一半）：**同一份提交信息在别的 run 上照样公开**。`ci.yml` / `guards.yml` / `dev-guards.yml` /
+  `gpu-evidence.yml` / `signing-status.yml` 都还是默认行为（没加 `run-name`），所以发布提交推进 `main` 时，那几行仍以
+  提交信息为名。要么给它们也加 `run-name`，要么就别在提交信息里写内部术语——**目前是后者**。
+- 抓不住（另一半）：**提交信息本身**。`git log` / commit 页面 / PR 里那段字照旧公开，`run-name` 管不到；这一层只有本节
+  + review 时人看一眼。没有任何门禁会因此变红——写一个能判「这段话是不是内部术语」的脚本不现实，别指望它存在。