OMP ACP dialect: classify and bound the extension surface #75

Summary

After parity, inventory every OMP ACP extension and classify each as a generic Orca primitive, an OMP-only dialect mapping, or ignored; implement the useful ones behind the dialect boundary.

Context

• 44madfire/orca#20 Phase C: consume OMP extensions through the extension boundary; never omp --mode rpc; never raw payloads to the renderer.
• OMP extMethods: speech.models.list, _omp/sessions/listAll, _omp/projects/list, _omp/chats/byCwd, _omp/usage, _omp/extensions, _omp/extensions/toggle (packages/coding-agent/src/modes/acp/acp-agent.ts:1120-1200 @53f253f); SessionInfo._meta; current_mode_update / session_info_update that Orca drops today (src/main/acp/acp-session-update.ts:80 @76d1b7b).
• Dialect boundary: src/main/acp/acp-dialects/acp-dialect.ts @76d1b7b.

Scope

• Classification table on this issue; implement chosen items (e.g. provider usage reports, plan-mode select, session titles) as normalized events/controls; unknown extensions ignored safely.
• Promote provider-neutral concepts as separate generic PRs once a second implementation exists.
• Later OMP contracts (e.g. omp-subagents-v1, omp-execution-cells-v1) are negotiated like orca-native-chat-v1 and land here, each with its own OMP-side definition.

Non-goals

• No parity work; no renderer plugin surface.

Depends on

• New OMP chats default to ACP when the provider satisfies orca-native-chat-v1 #74

Parity rows owned

• None (expansion).

Acceptance criteria

• Every OMP extension method/notification/_meta field is classified with a reason.
• Implemented items reach the renderer only as existing Orca event/control types.
• Unknown future extensions are ignored without errors.

Required tests

• Dialect fixtures per implemented extension; fuzzed unknown payloads ignored; payload size bounds.

Base branch

acp-migration (44madfire/orca).