fix(omp): an omp alert stays up until omp says the dialog closed (#798)

The four edits promised in the review of #798:

- An omp alert could clear while omp's dialog was still up. omp items got
  the same pane `capture` as Claude's, which the inbox re-reads with
  Claude's numbered-dialog parser. omp's dialog has no numbered rows, but an
  agent's plan above it does, so the list was parsed as the item's options,
  and once it scrolled out of the frame the item was resolved as answered in
  the terminal. An approval-only item now takes the frame once as `context`
  and gets no `capture`, like a screen-read item (web/screen-blocked.ts), so
  the module's `elicitation_complete` is the only thing that clears it. A
  route test puts a numbered list above an omp-shaped dialog and fails on
  the old code at both steps (options parsed, alert cleared).
- The reboot-restore install is dropped: the restore plan skips every CLI
  whose transcript is not `claude-jsonl` (omp's is `omp-jsonl`), so it never
  ran, and it sat after the start, when omp has already scanned its hooks.
- The docs that say which CLIs raise `blocked` and open alert-only items now
  name omp: api-reference, CLAUDE.md, architecture-invariants, an entry for
  `approvalHookFile` in cli-registry, and the skill with its plugin mirror
  (verbs.md listed omp among the modes where `blocked` is a 400, one line
  above the paragraph that says it works).
- Two comments: the schema's file-name rule is a pattern, not a closed list,
  and the marker check takes the marker anywhere in the file.

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

docs/cli-registry.md

@@ -223,6 +223,8 @@ still reading. A caller that asked only for `idle` keeps getting `idle`.
 
 `agentSkillInjection` says a CLI's sessions get the agent skill (`skills/codeman`) and its per-session preamble when the synced `agentSkillEnabled` setting is on; `agentSkillDir` says which workspace directory the CLI scans for skills, read through `agentSkillDir()` (hooks-config.ts), so no call site branches on a CLI id. Absent with the boolean on means `.claude/skills`, which is what the boolean meant before the field existed.
 
+`approvalHookFile` names the hook module Codeman installs into a local workspace for a CLI whose hooks are files rather than a settings block (omp: `<workspace>/.claude/hooks/pre/codeman-approval.ts`, written by `applyApprovalHookFile()` in hooks-config.ts from both create paths, after the launch pre-flight and only while `workspaceHooksEnabled` is on). The module forwards the CLI's own tool approval events to `/api/hook-event`, and that is all the field grants: `blocked` can fire and a dialog opens an alert-only Approvals Inbox item (`approvalHookAvailableForMode()` in session-wait-registry.ts, which says no for an adopted, remote or Docker session). It is deliberately not a `hooks` value: every reader of `hooks` takes a yes for Claude's full hook set, so `stop` stays a 400 for such a CLI. ⚠️ A bare `.ts` file name and nothing else (schema.ts): `clis.json` can set it, and it is written into the user's workspace. A file of that name without Codeman's marker is the user's own and is left alone, and a symbolic link at any path component is refused.
+
 | CLI | Skill directory |
 | --- | --- |
 | claude | `.claude/skills/codeman` |