fix(agents): launch omp through its local CLI instead of the npx bridge

[kaizhou-lab]

Problem

Migration 031 seeded omp as npx -y @oh-my-pi/pi-coding-agent acp with binary_name: "omp", copying the shape the Registry-listed npx rows use. That shape does not fit omp, and the row ended up paying both launch paths' costs while getting neither's benefit.

There is no Registry entry to conform to. Audited against the public ACP Registry catalogue: 11 of the 13 command='npx' builtin rows match their Registry entry's package and args exactly.

backend	Registry-declared distribution	our args	match
autohand	npx @autohandai/autohand-acp	-y @autohandai/autohand-acp	✅
codebuddy	npx @tencent-ai/codebuddy-code --acp	-y --package … codebuddy --acp	✅
deepagents	npx deepagents-acp	same	✅
dimcode	npx dimcode acp	same	✅
dirac	npx dirac-cli --acp	same	✅
glm-acp-agent	npx glm-acp-agent	same	✅
grok	npx @xai-official/grok agent stdio	same	✅
kilo	npx @kilocode/cli acp	same	✅
nova	npx @compass-ai/nova acp	same	✅
pi	npx pi-acp	same	✅
sigit	npx @smbcloud/sigit	same	✅
mimo-code	not listed	—	non-Registry builtin
omp	not listed	—	non-Registry builtin

For the 11, npx is the vendor's declared ACP distribution and bridging is correct — this PR does not touch them. omp is one of the two non-Registry builtins, so its bridge was chosen by analogy rather than from a declared distribution.

And the package is not an adapter. @oh-my-pi/pi-coding-agent ships bin: {omp: dist/cli.js}; omp acp is the vendor's own entrypoint (packages/coding-agent/src/commands/acp.ts, built on @agentclientprotocol/sdk), and the vendor publishes standalone binaries per release. Contrast pi-acp ("ACP adapter for pi coding agent") or @autohandai/autohand-acp ("ACP adapter for the Autohand CLI"), where binary_name names a different CLI the package wraps and the PATH gate is genuinely required.

The local binary was already mandatory. binary_name: "omp" makes probe_resolved_command fail the row with PrimaryMissing when omp is absent, and cli_probe::validate_with_budget already runs the local omp --version. Confirmed on a simulated clean machine (HOME pointed at an empty dir, minimal PATH):

c9e8a2f4   omp   Builtin   missing   CLI `omp` not on $PATH

So the row required a local install, probed it, executed it — and then spawned a different copy through npx.

What that cost, spawn to initialize response:

	cold npx cache	warm	local CLI
omp	81.0s	10.0s	0.7s

81s on a fast link, against a 30s handshake budget — the failure reported in iOfficeAI/AionUi#4009.

What changed

039_omp_direct_cli_launch.sql sets command='omp', args=["acp"], agent_source_info={"binary_name":"omp"} (bridge dropped). The release-lock entry goes with it, and the two lock-count assertions fall to 12.

Written as an UPDATE, not a re-seed. agent_capabilities and auth_methods hold what a live handshake learned on the user's own install; an ON CONFLICT DO UPDATE that lists them resets that to an integration-time snapshot (dead code on a fresh row, silent data loss on an existing one — the migration-023 shape). An UPDATE of the launch columns cannot reach those columns at all, so the guarantee is structural rather than review-dependent.

Verification

Real-path check, doctor run from this branch's build against a freshly migrated DB:

before:  c9e8a2f4  omp  Builtin  available  npx
after:   c9e8a2f4  omp  Builtin  available  /Users/zhoukai/.bun/bin/omp

Catalogue still 43 rows, availability unchanged at 41/2, and pi / mimo-code still resolve to npx — the change is scoped to omp. Seeded row after 039:

omp|omp|["acp"]|{"binary_name":"omp"}|[".omp/skills",".claude/skills"]

• cargo test -p aionui-db -p aionui-runtime -p aionui-ai-agent — all green (331 / 12 suites / 939 + 38)
• cargo clippy on those three with -D warnings — clean
• cargo fmt --all -- --check — clean
• just migration-check — passed
• Written test-first: both row assertions were watched failing for the right reason (command was Some("npx"); the lock still carried omp). The third test is a guard that passes before and after — its job is to catch a re-seed clobbering the probed handshake columns.
• Local workspace nextest not run (work-hours policy); CI's Test check is the authority.

Trade-off

omp's version is no longer pinned by acp-registry-npx-lock.json — it now tracks whatever the user has installed, exactly as the other direct-CLI builtins (qwen, agy) do. Version upkeep moves to the VERIFIED_* path.

Not in scope

• The other 12 npx rows stay. For the 11 Registry-listed ones, npx is the declared distribution and bridging is correct as-is. glm-acp-agent is a different shape again — a pure ACP package with no separate product CLI, whose binary_name gate looks questionable but which should drop the gate, not go direct; left for its own change with its own evidence.
• mimo-code stays on npx. Same non-Registry status, but its cold start is 16.0s (warm 3.6s) — inside the budget, so there is no failure to fix. Its npm package is a launcher that resolves a 95 MB platform binary, and the vendor's postinstall recommends a native install over npm; that is worth revisiting, but not under a bug fix.
• Install-path detection. platform_extra_bins() covers .cargo/bin, go/bin, .deno/bin, .local/bin, .volta/bin and nvm — but not ~/.bun/bin (where omp lands via bun) or ~/.mimocode/bin (where mimo's own installer puts it). A user who follows the vendor's install and lacks that directory in their login-shell PATH still gets a hidden row. That is the broader half of AionUi#4009 proposal 1 and affects every agent, so it belongs in its own change.

Migration number 039 is contested

039 is currently claimed by three open PRs — this one, #644 (039_project_knowledge.sql) and #815 (039_user_scope_assistant_ids.sql) — and 038 is likewise claimed by #815, #644 and the sidebar stack. Whichever lands first takes the number; the others must rebase and rename.

This is caught, not silent: scripts/migration/check-immutability.sh rejects duplicate numeric prefixes. Verified by putting both 039 files in a scratch checkout of main:

Duplicate database migration versions are not allowed.
Duplicate versions:
39: 039_project_knowledge.sql, 039_omp_direct_cli_launch.sql

(exit 1). So if another 039 merges first, this PR's CI turns red on rebase and the fix is a one-file rename — no risk of two different 039s reaching a release. Renumbering pre-emptively would not help: #644 also claims 040 and 041.

Closes iOfficeAI/AionUi#4009

Scope note on that link: the issue's timeout and npm-cache halves are covered (the first by #854, the second already shipped), and its primary ask — use the installed omp instead of forcing npx — is what this PR does. What it does NOT add is a scan of extra install locations such as %LOCALAPPDATA%\omp: detection still goes through the app's resolved PATH, so an omp that is installed but not on PATH stays hidden. That gap is agent-agnostic and tracked separately.