docs: mark P1 PEND-reason cluster verification done (070e9992)

Full job cluster verification on 2026-09-01 (HEAD a34p5yk) confirmed the
P1 reason restore end-to-end: TIME_WINDOW (night queue, window closed) and
HOST_UNAVAIL (all workers stopped) both surface via the jobs API; worker
restart without scheduler restart recovers dispatch (bug-1511 concern
disproven). Also records the third scheduler-framework merge regression
(pending_reason dropped from JOB_DEFAULT_COLUMN, fixed in 070e9992) and the
apiserver OPCode_notify-not-delivered note.

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/left_scheduler_work.md

@@ -205,7 +205,8 @@ spec 声称 36/36 任务完成，但 re-audit（research.md）发现缺陷。来
   - **P0**：main_reason 修复（首个 detail code 设为主因，集群验证 PEND 作业 main_reason 非 0 + reason_name）+ limit 插件 attach（host 限额→LIMIT_HOST+limit 名，全局限额→LIMIT_GLOBAL+limit 名）。**集群验证**：PEND 作业 API 显示 `main_reason:3 main_reason_name:"match_fail"` + 每条 host/res reason 带 reason_name。
   - **P1 部分**：队列状态（sched_queue_is_ready 非 stub，closed/inactive 队列不参选 + fcfs election attach QUEUE_CLOSED/DRAINING）；worker 过滤（sched_try_alloc_on_host_ 跳过 UNAVAIL/CLOSED worker + HOST_UNAVAIL）。
   - **⚠️ scheduler-framework 合并（2026-08-25）回归掉 P1**：P1 改动点（4e2ac86/ee79179）在旧 `fcfs.c`，框架合并用 `builtin_fcfs` 取代后旧 fcfs.c 成死路径；`resource.c`/`limit.c` 冲突取 theirs 直接丢；merge-fix 只补 dispatchwindow **字段**不补逻辑；验证从未跑。合并后 `sched_queue_is_ready`/`sched_job_is_ready` 是 `return 1` stub（core.c），仅 3 处 preason emit。
-  - **✅ P1 已恢复（2026-08-30）**：core.c 恢复 job 状态门 + queue 状态门；scheduler.c allocator 循环注入 `sched_queue_status_reason`（状态→QUEUE_CLOSED/DRAINING，时间窗→TIME_WINDOW，用 `xce_core_now` 虚拟时钟）；resource.c 恢复 worker 过滤+HOST_UNAVAIL；limit.c 恢复 LIMIT_GLOBAL/HOST attach。**全部 reason attach 走 allocator 线程（bug-1521 安全）**。单测通过（新增 `test_core_ready_gates.c`，scheduler 套件 52/53，唯一失败是既有的 admin-request 校验顺序问题与 P1 无关）。遗留：持续 closed 队列的作业被 picker 跳过（spec 契约）到不了 allocator → 收不到 reason（合并前 #17 后同样如此，非新回归）。集群验证待做。
+  - **✅ P1 已恢复（2026-08-30）**：core.c 恢复 job 状态门 + queue 状态门；scheduler.c allocator 循环注入 `sched_queue_status_reason`（状态→QUEUE_CLOSED/DRAINING，时间窗→TIME_WINDOW，用 `xce_core_now` 虚拟时钟）；resource.c 恢复 worker 过滤+HOST_UNAVAIL；limit.c 恢复 LIMIT_GLOBAL/HOST attach。**全部 reason attach 走 allocator 线程（bug-1521 安全）**。单测通过（新增 `test_core_ready_gates.c`，scheduler 套件 52/53，唯一失败是既有的 admin-request 校验顺序问题与 P1 无关）。遗留：持续 closed 队列的作业被 picker 跳过（spec 契约）到不了 allocator → 收不到 reason（合并前 #17 后同样如此，非新回归）。
+  - **✅ P1 完整集群验证通过（2026-09-01，HEAD a34p5yk 部署，commit 070e9992）**：正常基线 PEND→RUN→DONE；night 队列（窗口关闭）→ API `main_reason:8 time_window` + host 明细；停全部 worker → `main_reason:9 host_unavail` + t1/t2/t3 每 host 明细；worker 重启（不重启 scheduler）后 PEND 作业自动恢复 DONE（bug-1511 类担忧实测不成立）；daemon 零错误零 ASAN。**顺带发现并修复第 3 个合并回归（commit 070e9992）**：scheduler-framework 合并（3b6f53bb）冲突取 theirs 把 `pending_reason` 从 `JOB_DEFAULT_COLUMN`（models/jobs.go）丢弃 → PEND 作业 API 恒 null（scheduler/controller/apiserver store 全有 reason，仅默认查询字段不选）。**注意**：apiserver 只收 OPCode_push（dataset）不收 OPCode_notify（opcode 10），setpreason 后的 updateJob notify 不达 apiserver；reason 靠 join/创建时全量 dataset push 携带，实时性依赖 dataset push 触发。**LIMIT 仍未集群验证**（配置重建被预存 schema 违规挡住）。
   - **剩余（P2，超出 PEND reason 范畴，属 scheduler 特性开发）**：依赖 depend_cond / license / 保留 RsvID / exclusive / fairshare——机制本身在 scheduler 未实现（设计文档：调度器无处理）；机制落地后 reason 自动出现，MCP 侧无需改。已收尾：TIME_WINDOW 已实现（ee79179，2026-08-15）；`scheduler_pend_reasons` 工具（bjobs -p 等价）已上线（67abbfa，2026-08-15）。
 
 ### 5. 设计层加固（文档已写、代码零实现）