ci(m266): r3 只修注释的事实性，不动触发面（复审 p2-3items）

- ci.yml: 换算口径统一成「19:17 UTC = 本地（UTC+8）次日 03:17」（cron 是 '17 19'，
  原先内联写 17:19 差 12 小时，同一文件两套换算互相打架），全文只留这一种写法
- ci.yml: 通知收件人按文档原话改（发给「最后修改 cron 语法的人」，不是「默认分支的维护者」）
- ci.yml: 新增边界 ⑤ public 仓库 60 天无活动 scheduled workflow 自动 disable，
  这是「夜里那轮某天不再响且没人发现」的真实失效模式
- ci.yml: 「:30 也挤」无文档依据，改成文档原话（整点高负载 + 负载过高时排队任务会被 dropped）
- ci.yml: ③ 的 event 依赖断言改严：除 concurrency 组那一处与 runtime-smoke-macos 的 if 之外无 event 表达式
- docs: 归因改对——base(main) 上 :101 当时是对的，:246/:283 早就指偏（依赖安装步 / 一行注释），
  行号锚点本来就在腐，不是本次改动造成

行为面零改动：on / concurrency / jobs 的键值行与 r2 逐字相同（本提交的 ci.yml 差异全部是注释行）

.github/workflows/ci.yml

@@ -22,30 +22,39 @@ name: CI
 # 这是**故意的取舍**：抓得住「平台回归 T+1 就能看见」，抓不住「当天的错当天见」。dev 线的快守门
 # （fmt / clippy / guards / gpu 自测）在 dev-guards.yml，那边刻意不上全量 test / build，理由见其头部。
 #
-# schedule 的四条语义边界（省得下次重新查）：
+# schedule 的五条语义边界（省得下次重新查；每条都能在 GitHub 文档里对上原文）：
 #   ① 定时只在**默认分支**上生效：cron 跑的是 **main 的末梢**，dev 上尚未合入的内容**不在这一轮里**。
 #      所以「dev 已经有人天天看着了」这句话是**错的**——dev 线只有 dev-guards.yml 那几道快守门
 #      （fmt / clippy / guards / gpu 自测），全量矩阵在 dev 上一次都没跑过。另外这份文件必须先合进
 #      main，cron 才会第一次响：合并之前一次都不会跑。
-#   ② 失败可见性与 push 一样：`::error::` 注解由 test 作业的 shell 步骤自己产出，不读 event 上下文；
-#      定时任务的失败同样会通知默认分支的维护者。
-#   ③ 逐个 job 核过 `github.event` 依赖：整个文件只有 runtime-smoke-macos 的
-#      `if: github.event_name == 'workflow_dispatch'` 看 event，在 schedule 下为假 ⇒ 该 job 跳过
-#      （它本来就只是手动探针，见其注释）；其余 job 与矩阵里没有任何 event 表达式，夜间不会空转。
+#   ② 失败要向人喊话：`::error::` 注解由 test 作业的 shell 步骤自己产出，不读 event 上下文，这半条
+#      与 push 一样。但**收件人不是「默认分支的维护者」**——文档原话是 "Notifications for scheduled
+#      workflows are sent to the user who last modified the cron syntax in the workflow file"：
+#      谁最后一次改这行 `cron`，就一直收它的告警，所以这行 cron 的改动者要当成值班人。
+#   ③ 逐个 job 核过 `github.event` 依赖：除 concurrency 组那一处（`github.event_name`）与
+#      runtime-smoke-macos 的 `if: github.event_name == 'workflow_dispatch'`（schedule 下为假 ⇒ 跳过，
+#      它本来就只是手动探针）之外，其余 job 与矩阵里**没有任何** event 表达式，夜间不会空转。
 #   ④ 定时运行必须与 push main **分列到不同的 concurrency 组**：两者的 `github.ref` 都是
 #      `refs/heads/main`，同组 + `cancel-in-progress` 会让它们互相取消 —— 而**取消不是红**。
 #      一个经常被静默取消的夜间入口比没有更坏：「昨晚没报错」会变成一句假话。所以 group 里带了
 #      event_name（证据强度见 `concurrency:` 上方那几条注释，别当成已在 runner 上实证过）。
+#   ⑤ **它自己会悄悄停**：public 仓库的 scheduled workflow 在仓库 60 天无活动后会被**自动 disable**
+#      （文档："In a public repository, scheduled workflows are automatically disabled when no
+#      repository activity has occurred in 60 days"）。这是「夜里那轮某天不再响、而且没人发现」的
+#      真实失效模式，比红更隐蔽；本仓若是 public 就适用，发现入口不跑了先看那条 disable 提示。
 #
-# 时间：`cron` 一律 UTC，所以这里写死 `17 19 * * *` = **本地（UTC+8）每天 03:17**。
-# 分钟刻意避开 :00 / :30——整点是 GitHub 定时队列最挤的时候。
+# 时间：`17 19 * * *`。GitHub 按 UTC 解释 cron（文档："By default, scheduled workflows run in UTC"），
+# 所以它是 **19:17 UTC = 本地（UTC+8）次日 03:17**，本文件不再出现第二种换算口径。
+# 为什么是 17 分：文档只说 "the start of every hour" 是高负载期，且 "If the load is sufficiently high
+# enough, some queued jobs may be dropped"（负载过高时排队任务会被**丢弃**，不只是延迟），并建议错开
+# "a different time of the hour"。文档没有「:30 也挤」这条依据，所以这里只避开整点。
 
 on:
   push:
     branches: [main]
   pull_request:
   workflow_dispatch:
-  # 夜间全量矩阵（M266 / T30，理由与取舍见文件头）：17:19 UTC = 本地 03:17。
+  # 夜间全量矩阵（M266 / T30，理由与取舍见文件头）：19:17 UTC = 本地次日 03:17。
   schedule:
     - cron: '17 19 * * *'