feat: add openmax-bridge, a JSON-RPC over stdio front end

[Max17190]

Why

--stdio (versioned and pinned in #46) is the contract external hosts build against, but every host still has to learn openmax's native JSONL envelope to use it. A host that already speaks JSON-RPC 2.0, the common line protocol for editor and tool integration, had no path in. This adds that path as a thin, separate front end so integration does not require touching the harness core.

Summary

• New crate crates/bridge (open-max-bridge, binary openmax-bridge). It exposes a running session over line-delimited JSON-RPC 2.0 on stdio and is a client of the openmax-stdio/1 contract: it spawns openmax --stdio (or $OPENMAX_BIN) and translates both directions. The core is unchanged and gains no dependency.
• Methods. initialize (answered from the child hello: server, protocol_version, version, session_id), prompt { text } (streams update notifications, resolves with { stop_reason } at the turn's done), cancel, approve { approval_id, approved }, shutdown. A request carries id; a notification omits it. A second prompt while one is in flight is a JSON-RPC error.
• Approvals and streaming. Every child event is forwarded as one update notification, approval requests included; the host answers with approve. Closing stdin drains the in-flight turn, mirroring the underlying protocol.
• Structure. translate.rs is a pure mapping layer with no I/O (parsing, request-to-command mapping, child-line classification, JSON-RPC builders), unit-tested exhaustively. main.rs is thin subprocess plumbing: two reader threads feeding one channel, hello read synchronously so initialize never races the child's first write.
• README documents the bridge methods and the update stream.

Test Plan

• cargo test --workspace (6 bridge + 145 core + 59 tui)
• cargo clippy --all-targets --locked -- -D warnings
• Unit coverage: every method parse and its error cases, request-to-command mapping, child-line classification (hello, done, update, protocol_error, non-JSON, no-type), initialize extraction, and JSON-RPC builder shape
• Manual end-to-end against a real openmax --stdio: initialize resolves with protocol_version and session_id; a prompt streams update notifications and its request resolves at done with the turn's stop_reason; stdin close drains and exits cleanly

[greptile-apps]

Greptile Summary

This PR adds a JSON-RPC 2.0 bridge for driving an Open Max stdio session. The main changes are:

• A new openmax-bridge workspace binary.
• JSON-RPC methods for initialization, prompts, cancellation, approvals, and shutdown.
• Streaming child events through update notifications.
• Translation tests and bridge usage documentation.

Confidence Score: 5/5

The latest fixes appear safe to merge.

• Prompt notifications now participate in turn tracking.
• Child exits and failed writes now resolve pending requests with errors.
• Initialization and protocol-version handling now reject the previously broken cases.
• No additional distinct blocking issue qualifies for this follow-up.

Important Files Changed

Filename	Overview
crates/bridge/src/main.rs	Adds subprocess management, request dispatch, prompt lifecycle tracking, and stdio event forwarding.
crates/bridge/src/translate.rs	Adds JSON-RPC parsing, child command translation, event classification, response builders, and unit tests.
crates/bridge/Cargo.toml	Defines the new bridge binary and its serde_json dependency.

_{Reviews (2): Last reviewed commit: "fix: harden bridge request lifecycle and..." | Re-trigger Greptile}