grok adapter passes an unknown MultiEdit tool prefix, so grok sessions fail to launch #1204

Symptom

Every grok session dies immediately at spawn. The session shows up as awaiting input with the prompt still queued and zero output; the only trace is one line in the daemon log:

INFO adapter: stderr: Error: --allow "MultiEdit(/Users/moon/.local/share/construct/sessions/<sid>/widgets/**)": unknown tool prefix: MultiEdit

Because the failure lands on the adapter's stderr and the session never produces a transcript event, it looks like a hung agent rather than a launch error.

Cause

grok_allow_args() in crates/adapter-grok/src/lib.rs builds an allow rule per policy path for a hardcoded tool list:

for tool in ["Write", "Edit", "MultiEdit"] {
    out.push("--allow".into());
    out.push(format!("{tool}({glob})"));
}

The grok CLI validates tool prefixes and rejects unknown ones, exiting before it does anything else. MultiEdit is not one of its tools.

Confirmed on grok 0.2.118 (1e1687c1cf6a) [stable]:

$ grok --allow "MultiEdit(/tmp/**)" -p "hi"
Error: --allow "MultiEdit(/tmp/**)": unknown tool prefix: MultiEdit

$ grok --allow "Edit(/tmp/**)" --max-turns 1 -p "reply with OK"
OK

Write and Edit are fine; MultiEdit alone is fatal. Since the widgets directory is always in the policy's allow paths, this affects every grok session, not an edge case.

Suggested fix

Drop MultiEdit from the list. Worth considering alongside it:

• Validate or feature-detect tool prefixes per harness rather than sharing one hardcoded list across adapters, so a CLI renaming or removing a tool degrades instead of bricking the harness.
• Surface adapter spawn failures as a session error event instead of leaving the session in awaiting input with no output — the current failure mode is silent and looks like a hang.

Repro

1. construct new grok (or spawn a grok subagent) with any prompt.
2. Session goes to awaiting input, pending_input: true, no output.
3. grep MultiEdit ~/.local/state/construct/daemon.log