feat(hook-policy): configurable policyMode + failMode for workflow adaptation

[tizerluo]

What

HOLO's hook was an all-or-nothing affair: the only way to adapt to different workflows was to uninstall the hooks entirely, losing the safety net AND the observability. This PR makes the enforcement posture per-config configurable so you can keep HOLO attached while matching the workflow's risk posture.

Closes the "I have to disable hooks to get work done" pain point reported during the multi-agent-workflows integration.

Two new config fields (defaults preserve current behavior)

// .agent-loop/config.json
{
  "hookPolicy": "enforce",   // enforce | observe | disable  (default: enforce)
  "hookFailMode": "closed"   // closed | open                (default: closed)
}

field	value	meaning
hookPolicy	enforce	Current behavior: block per policy chain (default-deny + allowlist).
	observe	Record every command but never block — the runtime equivalent of observe-runner, implemented inline so no build/hooks/router changes are needed.
	disable	Hook fully inert (no recording, no blocking).
hookFailMode	closed	Current behavior: when storage is unavailable, deny lifecycle commands fail-safe.
	open	When storage is unavailable, allow lifecycle commands so a broken state DB does not freeze the session. Destructive/shell-control commands remain enforced (they are storage-independent).

One new CLI command

agent-loop hooks disable --repo /path/to/repo   # pause enforcement (binding kept)
agent-loop hooks enable  --repo /path/to/repo   # resume

Uses the existing disabled status on HookBinding (the router already filtered it out) — upsertHookBinding accepted status from the start, it just had no CLI entry point. disable guards against silent upsert when no binding exists.

Why this shape

• observe is implemented inline in evaluatePreToolUseHook rather than swapping the runner in build:hooks. Three lines at the entry point achieve the same runtime effect without touching esbuild config, the router, or file layout — far smaller blast radius than the originally-planned build refactor.
• fail-open only relaxes storage-gated lifecycle commands. Destructive commands (git reset --hard, force push, gh repo delete) and shell-control operators are storage-independent and stay enforced under every mode. The security floor never moves.
• defaults are enforce + closed. Existing configs without these fields behave exactly as before.

Commits (review ordered)

1. PR1 — plumb hookPolicy / hookFailMode through schema → config defaults + validation → types → HookPolicyInput. No behavior change.
2. PR2 — hooks disable/enable CLI subcommands.
3. PR3 — hookFailMode=open downgrades storage-gated lifecycle denials in the fail-safe branch.
4. PR4 — hookPolicy=observe|disable early-return in evaluatePreToolUseHook (observe records, disable is inert).
5. fix — addresses code-review + simplifier findings (see below).

Verification

• tsc --noEmit clean.
• pnpm test — 426 / 426 passing.
• pnpm prepack (build) clean.
• Note: runs dashboard smoke as structured release-readiness output is flaky on parallel runs due to HTTP port contention; it passes in isolation on both main and this branch, so it is pre-existing and unrelated.

Review-gate findings (already addressed in commit 5)

This PR was initially merged-to-branch without the double-review gate. That gate was then run (code-reviewer + simplifier) and six issues were found and fixed:

• (P1) observe + corrupt storage: recordHookDecision could throw and discard the observe allow decision → wrapped in try/catch so observe honors its "never block" contract unconditionally.
• (P2) isStorageGate allowlist contained two strings (lifecycle_state_gate, publish_prerequisites) that no deny() ever produces — removed, comment added.
• (refactor) disable/enable CLI branches were near-duplicates — merged (-8 lines).
• (cleanup) HookPolicyInput.hookPolicy dropped redundant | undefined.
• (P2) hooks disable no longer silently upserts a disabled binding when none exists.
• (test) added "observe still allows destructive when storage corrupt" to lock in the P1 fix.

Out of scope (deliberately)

• generic-loop PR-state-machine exemption — has architectural/review implications (conflicts with docs/trust-and-safety.md, no replacement gate). Tracked separately; not in this PR.
• Custom allowlist extension (customAllowed) — tracked separately.

Compatibility

No impact on local Codex installations that do not have HOLO installed. Only takes effect once a user opts in via agent-loop install-hooks and sets the new fields.

[tizerluo]

Review note from Codex

我同意这个 PR 的方向：现在 hook 太紧，确实需要给工作流留出解绑/观察/故障降级能力。下面两个点不是反对放宽，而是希望这个“关闭/放宽”开关不要让用户产生误判。

1. hookPolicy=disable 的实际范围需要说清楚

当前实现只让 PreToolUse 变成 allow/no-record，但其他 hook 事件仍会走 runObserveOnlyHook -> observeCodexHook，继续记录 PostToolUse、SessionStart、Stop 等事件。

如果产品定义是“disable = 只关闭 PreToolUse enforcement”，那现在行为可以接受，但 PR 文案里的 “fully inert / no recording” 需要改掉。

如果产品定义是“disable = 所有 HOLO hook 完全 no-op”，那需要在 observe runner 或 observeCodexHook 层也读取 config，hookPolicy=disable 时直接跳过记录，并补一个非 PreToolUse 的回归测试。

2. agent-loop hooks disable --repo 在多 session binding 下不要假成功

现在无 --session 时，只要该 worktree 有任意 binding，hasHookBinding 就会返回 true；随后 upsertHookBinding({ status: disabled }) 在多个 session-scoped binding 存在时可能新增一个 disabled unscoped binding，而不是关闭已有 active session bindings。

结果是命令看起来成功，但真实 active session binding 还在，hook 仍可能继续生效。这和“我想临时解绑/别再拦我”的目标相反。

建议二选一：

• 无 --session 时禁用该 repo/worktree 下所有 binding；或
• 如果存在多个 session binding，就返回明确错误，要求用户指定 --session，不要创建一个不会生效的 disabled binding。

我认为第二点应当在合并前修。第一点至少要改文案；如果目标真的是 fully inert，也应当一起修实现。