Harden qx-scheduler DAG maintenance and state persistence

Start with the qx-scheduler 5-second tick chain: ensureRunForDate, ListRunnableRunIDs, Loop.Tick, runNode, and ensureRunForDate persistence. Review how calendar coverage, runnable states, execution contexts, and node upserts flow through recovery and terminal writes. Run the targeted scheduler/cmd tests and build qx-scheduler; done means all listed acceptance criteria pass without changing the deferred follow-ups.

Description

重点审计 qx-scheduler 的 DAG 对账、runnable run 发现、门禁、lease/CAS claim、异步执行、验证及终态写回后，确认 4 个会影响采集正确性或数据库负载的高价值问题。

Related to #1。

Confirmed Problems

1. localATradingDate 未区分“覆盖内休市”和“日期超出本地日历覆盖”，可能把未来/过期日历静默判为休市并跳过整条采集 DAG。
2. ListRunnableRunIDs 漏掉只剩 aux degraded 重试或 aux reopen marker 的 run，维护梯子可能永久停止。
3. runNode 部分终态/修复重开写回继承执行 context；验证完成后若 deadline 到达，成功状态可能无法落库并重复执行。
4. ensureRunForDate 每 5 秒无条件重写所有 pending 节点；UpsertNode 的 SELECT+DELETE+INSERT 造成 WAL/index 写放大并放大 SQLITE_BUSY。
5. 生产模板缺少统一依赖闭包与无环回归保护。

Evidence

• 主链：5 秒 tick → ensureRunForDate → ListRunnableRunIDs → Loop.Tick 恢复/门禁/lease/CAS claim → 异步执行/续租 → 终态写回。
• 现场存在大量 SQLITE_BUSY/slow tick；稳定 pending 模板仍会被每轮重写。
• 当前 task_nodes 的 pending 节点中存在被 cancelled/failed 上游直接或传递阻塞的历史链，runnable 发现与维护态完整性直接决定是否还能自愈。

Acceptance Criteria

• 日历覆盖外日期返回 error，覆盖内休市仍返回 false。
• 同日 aux degraded 与 aux reopen-pending run 保持 runnable，普通 terminal run 不被扩大纳入。
• 验证完成后的所有终态状态可在执行 context 已取消时可靠持久化。
• 稳定 pending DAG 的 ensure tick 不产生节点写入，模板变化仍能对账更新。
• 生产模板依赖闭包完整且 DAG 无环。
• scheduler/cmd 定向测试与 qx-scheduler 构建通过。

Deferred Follow-ups

本 Issue 不顺带改变以下语义，后续单独处理：control reset/cancel TOCTOU CAS、backlog repair deadline、snapshot.gc retention、catalog freshness bypass、running repair reopen、control_events retention、stdout/stderr 有界捕获。