docs(logbook): record stale harbor repair blocker

docs/LOGBOOK.md

@@ -1,3 +1,17 @@
+## 2026-07-01 — 13:55 CD waiting behind stale Harbor 110 repair readback
+
+**照主線修正的問題**：
+- 最新 Gitea queue 顯示 main CD 仍 `Waiting`，同時 Harbor 110 repair lane 顯示 `Running`；但 repair jobs API payload 對不到目前 workflow/run，容易讓 priority work order 只看到泛稱 waiting 或 SSH auth stalled。
+- `ops/runner/read-public-gitea-actions-queue.py` 新增 `harbor_110_repair_visible_running_jobs_api_stale` 與 `current_cd_waiting_behind_harbor_110_repair_running`，把目前狀態分類為 `blocked_current_cd_waiting_behind_stale_harbor_110_repair_readback`。
+- `ops/runner/verify-awoooi-non110-cd-closure.py` 同步把這個狀態納入 closure blocker，next action 指向重新讀 public queue、驗證 Harbor 110 repair jobs payload 與 110 local control path，而不是誤判成 deploy code failure。
+- 110 bounded diagnosis 仍是 `SSH_AUTH user=wooo mode=publickey classification=publickey_offer_timeout`、`NODE_LOAD_CLASSIFIER=load_not_high`、多個 legacy runner systemd unit `systemctl_show_timeout`。
+
+**驗證**：
+- `python3.11 -m pytest ops/runner/test_read_public_gitea_actions_queue.py ops/runner/test_verify_awoooi_non110_cd_closure.py -q`：`45 passed`。
+- live queue readback：`status=blocked_current_cd_waiting_behind_stale_harbor_110_repair_readback`、`harbor_110_repair_visible_running_jobs_api_stale=True`、`current_cd_waiting_behind_harbor_110_repair_running=True`。
+
+**邊界**：只改 Gitea public queue readback / closure verifier / tests / LOGBOOK；未使用 GitHub / `gh` / GitHub API；未 workflow_dispatch；未讀 secret / token / `.env` / raw sessions / SQLite / auth；未讀 authorized_keys 內容或 `.runner` 內容；未執行 110 runtime apply；未 reboot / restart Docker / Nginx / K3s / DB / firewall。
+
 ## 2026-07-01 — 13:11 P0-7 Windows 99 VMware autostart controlled apply
 
 **照主線修正的問題**：