fix(recovery): honor 110 ssh command-path readiness

docs/LOGBOOK.md

@@ -22,7 +22,26 @@
 **邊界**：未重啟主機，未 restart Docker / Nginx / K3s / DB / firewall，未刪 pod，未讀 secret value / token / `.env` / raw sessions / SQLite / auth，未寫 credential escrow marker，未使用 GitHub / `gh` / GitHub API，未恢復 generic runner。
 
 **下一步**：core cold-start 已 GREEN；主線下一步改為 DR offsite credential escrow non-secret evidence review，並保留 MOMO product-data source-arrival gate 監控，等正式 source 到達後由原匯入 pipeline 更新，不做手動 DB 偽更新。
+## 2026-07-01 — 23:42 110 SSH command-path effective readiness 修正
 
+**照主線修正的問題**：
+- 110 實測 `wooo@192.168.0.110` command path 可執行，Harbor `/v2/` 回 `401` ready；但舊 `diagnose-110-ssh-publickey-auth.sh` 只看 `ssh true` verbose timeout，API receipt / Gitea queue parser 仍會把 `classification=server_accepts_key_then_timeout` 判成 active `harbor_110_remote_ssh_publickey_auth_stalled`。
+- `diagnose-110-ssh-publickey-auth.sh` 新增 `SSH_COMMAND_PATH user=wooo ... classification=command_path_ready` 非敏感機器可讀 probe；若 command path 成功，舊 verbose timeout 只保留 raw evidence，不再當 effective blocker。
+- `repair-110-ssh-publickey-auth-local.sh --check` 現在遇到非 root `sshd -t` hostkey / 權限限制時輸出 `SSHD_CONFIG_SYNTAX=unverified_requires_root` 並繼續讀非敏感 account / shell / authorized_keys metadata；`--apply` 仍保持嚴格，不會在 syntax check 失敗時默默套用。
+- `harbor_registry_controlled_recovery_receipt.py`、`read-public-gitea-actions-queue.py` 與 `verify-awoooi-non110-cd-closure.py` 已加入 command-path effective readiness，讓 production readback 能從假 SSH stalled 轉到真正的 controlled CD lane / runner readiness blocker。
+
+**驗證**：
+- `python3.11 -m py_compile apps/api/src/services/harbor_registry_controlled_recovery_receipt.py ops/runner/read-public-gitea-actions-queue.py ops/runner/verify-awoooi-non110-cd-closure.py`：通過。
+- `bash -n scripts/reboot-recovery/diagnose-110-ssh-publickey-auth.sh scripts/reboot-recovery/repair-110-ssh-publickey-auth-local.sh`：通過。
+- `DATABASE_URL=sqlite+aiosqlite:////tmp/awoooi-codex-api-test.db PYTHONPATH=apps/api python3.11 -m pytest apps/api/tests/test_harbor_registry_controlled_recovery_receipt.py scripts/reboot-recovery/tests/test_cold_start_monitor_bounded_probes.py ops/runner/test_read_public_gitea_actions_queue.py ops/runner/test_verify_awoooi_non110_cd_closure.py -q`：`87 passed`。
+- `DATABASE_URL=sqlite+aiosqlite:////tmp/awoooi-codex-api-test.db PYTHONPATH=apps/api python3.11 -m pytest ops/runner/test_cd_controlled_runtime_profile.py -q`：`41 passed`。
+- live read-only diagnosis：`SSH_AUTH user=wooo mode=publickey ... classification=server_accepts_key_then_timeout` 與 `SSH_COMMAND_PATH user=wooo rc=0 classification=command_path_ready marker_seen=true remote_user_match=true` 同輪出現；node load classifier `load_not_high`。
+- live patched local check：`SSHD_CONFIG_SYNTAX=unverified_requires_root`、`USER_STATUS user=wooo exists=1`、`ACCOUNT_METADATA ... account_locked=false shell=/bin/bash shell_executable=true`、`AUTHORIZED_KEYS_STATUS ... exists=1`；未印出 authorized_keys 內容。
+- `git diff --check`：通過。
+
+**邊界**：未使用 GitHub / `gh` / GitHub API；未讀 secret / token / `.env` / raw sessions / SQLite / auth；未重啟主機，未 restart Docker / Nginx / K3s / DB / firewall，未 workflow_dispatch，未 force push，未恢復 generic runner。
+
+**下一步**：commit / push Gitea `main`，等 CD 成功後讀回 production priority / Harbor recovery receipt；預期 P0-006 不再停在假 SSH stalled，而會顯示 controlled CD lane config / registration / service readiness 的真 blocker。
 ## 2026-07-01 — 21:32 cold-start 假 WARN 收斂與 live monitor 同步
 
 **照主線修正的問題**：