[Bug]: OMP worker-start prompt is never submitted — OMP's large-paste menu consumes the injected Enter (1.4.199 / OMP 18.1.19)

What happens

worker-start against an OMP terminal reports success (stage: input_accepted, effects[dispatch_input].state="accepted") but the worker never starts. The rendered screen shows the whole Task prompt collapsed in the composer as a paste chip:

╭──  #1 ───╮
│You are wor…│
│Your coordi…│
│Your task I…│
╰ +144 lines ╯
 π > ◑ Opus 4.6 1M  >  ~/orca/projects/<repo> > ⑂ main

The Dispatch sits ready / dispatched forever and the coordinator's check --wait never returns a worker_done. One extra Enter in the pane submits it, so unattended orchestration stalls exactly where it is supposed to be unattended.

Why it happens

Two behaviours meet:

1. OMP 18.1.19 opens its "Pasted N lines" menu for any bracketed paste reaching paste.largeMenuThreshold lines (default 100): Attach as a wrapped block / Attach as local file / Paste inline. A supervised Task prompt reaches that size easily — Orca's dispatch preamble alone is ~64 lines, plus the Task spec — and the OMP bundle shows the menu is skipped only when the paste is flagged submitAfterPaste, which OMP sets only when the Enter arrives in the same input chunk as the paste terminator (ESC[201~).
2. Orca writes the paste and the Enter as two separate PTY writes: write(pastePayload), wait getAgentPromptSubmitDelayMs() (500 ms + ingest), then write('\r') (src/main/runtime/orca-runtime-write-terminal-agent-prompt.ts).

So the injected Enter lands on the menu and accepts its default option (Attach as a wrapped block), which collapses the prompt into the composer chip instead of submitting the Task.

Workaround for anyone else hitting it: launch the OMP pane with a run-local config overlay containing paste: { largeMenuThreshold: 0 } (OMP's --config <path>). The paste then collapses to a chip that the same injected Enter submits.

Reproduction (Orca 1.4.199, OMP 18.1.19, macOS arm64)

orca orchestration worker-start --spec "<64 filler lines + instruction>" --worktree current --agent omp

• 144-line prompt → menu → chip in composer → writes = paste only, no turn (screenshot above).
• Same spec with 5 lines (≈72 lines total, below the threshold) → submits normally, turn starts.
• Byte-for-byte replay of Orca's injection against a real OMP TUI (ESC[200~ … ESC[201~, then \r ~600 ms later): 99 lines submit, 100 lines open the menu, and only a second Enter submits. Sending ESC[200~ … ESC[201~\r in one write submits immediately with no menu.

Proposed fix

Join the submit to the paste frame for OMP only: write pastePayload + '\r' in the existing single PTY write and skip the settle delay for that agent, keeping every other agent (and the codex paste hazard in #11343) unchanged. I have that patch + tests ready and will open a PR right after this issue.