[welldoingk]

Closes #412.

What changed, and why

Herdr reports an OmO session as agent: "pi", and pi had no adapter. When OmO's built-in
ask_user_question / request_user_input tool opened a single-choice question, the phone showed
no buttons, and the composer stayed open on a screen where typing would land in the dialog.

This adds a pi adapter, scoped to what was captured: OmO 5.1.30's one-question,
single-select Ask screen and its composer.

• web/src/lib/harness/pi/ask.ts lifts that dialog as a prompt-select card. A tap sends
  the option's printed digit alone (["2"]). OmO's key handler activates the option and
  submits a one-question single-select at once, which was probed live. No arrow walk and no
  trailing Enter, and no new action-layer recipe. Cancel sends the printed esc.
• web/src/lib/harness/pi/composer.ts reads the pi editor in both layouts Herdr reports as
  pi: stock pi (draft at column zero) and OmO (❯ prompt), each between two rules over styled
  status rows, with the running-turn label on the top rule. This matters beyond OmO: registering
  any pi adapter moves every pi pane from the one-step send to the guarded send, so without it
  a stock pi send would be refused. A live phone send to stock pi 0.85.1 typed, read back and
  submitted.
• cancelKey: "Escape" plus modalOnScreen, which needs one of the three captured Ask footers.
  Multi-select and the Other editor therefore stay raw and get the unread-dialog card.
• Registry entry, ledger line (how: "capture"), seven fixtures pi--omo-v5130-*.txt and two
  stock pi fixtures pi--v0851-*.txt.

Deliberately not lifted

• Multi-select. enter toggle / tab next / Submit: Enter toggles rather than submits, and
  no shared model carries that recipe.
• The focused Type your own answer... row and its editor. Captured and kept raw. No digit
  buttons, no composer typing.
• Several questions, the review/comment tab, answered questions, more than nine options,
  and unknown footers.
• Stock pi question extensions. Stock pi's built-in tool registry has no question tool; an
  extension draws a different screen (["N", "Enter"], [ ]/[x]), which is what feat(harness): add pi harness adapter and interactive dialog lifting #397 targets.
  Those screens keep the raw mirror here.

Relation to #397

#397 also registers pi, for pi 1.1.0 with a question extension. The two grammars do not overlap:
OmO's screen is the Ask user panel with 1-9 select … esc cancel. Whichever lands second has
to compose both into one adapter. I am happy to rebase onto #397 if that is preferred.

Evidence

• Fixtures captured 2026-10-12 from a sandbox Herdr pane at 113 columns with
  herdr pane read --format ansi --raw, cut to the dialog frame. No secrets.
  See web/src/fixtures/panes/README.md and web/src/lib/harness/pi/ASK_NOTES.md.
• Terminal probes: digit 3 → Color: Blue, dialog closed. Down/Up move only the pointer.
  Enter on Other opens the editor. Escape cancels.
• Live, phone-sized headless Chromium, paired to this branch's bridge: the Chat view drew
  the card with all three options and their descriptions. With the pointer on Red, a tap on
  Green answered Color: Green and the agent replied BROWSER_ANSWER=Green.
• describeAdapterConformance over the two lifted captures, with every other corpus file as
  foreign or neutral.

Checks

• bun run build (version gate, root + web typecheck, bundle)
• bun run lint
• cd web && bun run test: 403 files, 22,883 passed
• bun test ./bridge ./cli ./scripts (5543 + 2025 + 296, 0 fail), collie-ctl.test.sh, and every shell suite after collie-cli.test.sh
• scripts/collie-cli.test.sh hung locally at the systemd collie start scenario (WSL host); this branch touches only web/src, so CI is the evidence for that suite

CHANGELOG line for the maintainer

Under ### Added:

• OmO questions get answer buttons in Chat. A single-choice question from OmO, which Herdr
  reports as pi, now shows its options as buttons; multi-select and typed answers stay in the
  terminal view.

[welldoingk]

Withdrawing this for now. Live testing on a wide pane found that OmO draws a sidebar on the same rows as the dialog, including the rules, and the sidebar text changes every second. That breaks both detection and the tap's screen binding. I will reopen once that is handled and re-verified.