Add an OMP harness driver

[schickling-assistant]

Narrowed 2026-08-30. Two of the three elements originally scoped here have shipped. What remains
is DING delivery, and it is genuinely unproven rather than merely unimplemented.

Delivered, no longer in scope

• Driver variant and session surface. Add omp as a fifth native driver #346 (54daa43, 2026-08-26) added src/omp_session.rs and
  Command::Driver(DriverCmd::OmpSession). axe agent launch --harness accepts omp, and managed
  seats declaring it reach a live PTY today.
• Version admission. Beyond the original scope: Admit omp 18.0.9 to the version gate, with the measured evidence #369 admitted 18.0.9 against the five OMP-R05
  probes, and Gate omp and opencode on the minor, not the exact version #370 re-keyed the gate on the MINOR, so SUPPORTED_OMP_MINORS = [(18, 0)]
  (src/omp_session.rs:55) admits any 18.0.x.

Remaining: prove DING delivery against a live omp pane

src/ding/harness/ contains claude.rs, codex.rs, opencode.rs and mod.rs, and no omp.rs.
That absence is not itself the gap — there is no pi.rs either and PiDriver has shipped for a
long time. Coverage is not per-driver: adapters are probed positionally, every adapter is asked to
locate a composer, and the lowest one wins. The failure state is therefore not "unknown harness" but
src/ding/mod.rs:264 — no maintained adapter could locate a composer on the pane, so nothing is
proven either way.

The narrow question:

Can an existing adapter locate the composer on a live omp pane?

Both outcomes are consistent with everything measured so far. If omp renders OpenCode's TUI, then
opencode.rs locates it and DING delivery already works with no new code. If omp's chrome diverges,
every omp seat lands in the mod.rs:264 coverage gap and silently receives nothing — which is the
worst shape of failure, because the seat looks healthy.

Acceptance test

Send one bus message to a live omp-harness seat and confirm it is delivered and processed — not
merely that st2 message send returned success.

Note that reaching a live PTY and driving a model turn does not settle this. A seat can be alive
and permanently undeliverable, because the composer probe is a separate surface from session startup.

Runnability

This is runnable now. dev3.eggisried-orchestrator is a live omp pane (omp 18.0.11), so the probe
target exists. Model-pinned omp seats are currently parked on an unrelated runtime-profile issue
(schickling/dotfiles#2203), but that does not block this test, which only needs one live omp pane.

Downstream half: schickling/dotfiles#2022. Driver boundary: #162.

Posted on behalf of @schickling

field	value
agent_identity	dev3.compoundingtech-lead
session	dev3.178897f4
agent_persona	teamlead
agent_supervisor	dev3.cos
agent_tool	Claude Code
agent_tool_version	2.1.251
agent_runtime	Claude Code 2.1.251
tooling_profile	dotfiles@000f2b3