Add official support for ACP (Agent Client Protocol)

[jmjoy]

Problem
Reasonix currently does not support ACP (Agent Client Protocol). This limits Reasonix's interoperability with other ACP-based systems and reduces its usefulness in multi-agent and cross-platform workflows. Users who want to integrate with ACP-compatible tools currently have to build custom adapters or workarounds.

Proposed change
Add official ACP support to Reasonix, including:

• Implement the required parts of the ACP specification, such as authentication, message formats, and communication flow;
• Design and implement an internal ACP adapter layer for Reasonix, ideally with a pluggable architecture;
• Provide documentation, configuration options, and examples so users can integrate and test ACP support easily.
  If possible, support additional ACP features and future versions to improve compatibility and extensibility.

Alternatives considered

• Using community-maintained plugins or custom scripts to approximate ACP compatibility, but this would be harder to maintain and less reliable.
• Building a separate API proxy or translation layer, but that adds complexity and still would not provide native protocol support.

Scope check

• This belongs in core reasonix (not better as a separate npm package)
• I've read CLAUDE.md and CONTRIBUTING.md

[esengine]

Thanks for writing this up. A few thoughts on where it lands.

The IDE-integration non-goal in the README is narrower than it might read: it's about not trying to replace the editor itself — no file tree, no buffer model, no LSP. A protocol interface that lets external surfaces drive the loop is a different category, and the embedded web dashboard at /dashboard is already an example. So "reasonix as an ACP server" isn't categorically out, just not landing yet.

What's holding it:

1. Adoption story is thin. ACP is mostly a Zed effort right now, with HTTP/WebSocket transport still flagged WIP upstream. If Zed turns out to be the only client, the maintenance surface doesn't pay for itself. The VSCode / Cursor asks I've actually seen want a native editor extension — those editors don't speak ACP, so this issue doesn't address them.

2. No concrete workflow in the proposal. Generic interoperability benefits don't move this on their own. If someone's actively wanting to drive Reasonix from Zed (or another ACP host) with a real flow in mind, drop the use case here — that's the data that turns "could" into "should".

3. Implementation is plausible, not trivial. A reasonix acp entry point that swaps the TUI for a JSON-RPC stdio adapter — mapping internal events (tool_call / edit_block / plan_proposed) to ACP frames, and ACP requests back to loop inputs — would be on the order of 1-2 weeks of focused work. The cache-first loop doesn't care what's rendering it; only the IO layer changes. Cache-prefix stability is preserved.

Labeling rfc and leaving open. If anyone wants to spike a draft PR — even just the ACP handshake plus a single tool-call round-trip end-to-end — happy to review and expand the scope from there.