feat(agent): Maple-owned mid-run message queue

docs/agent-mode-acp.md

@@ -110,7 +110,7 @@ Goose already implements many of these semantics, but at Maple's pinned revision
 | Embedded binary resources                  | No              | Medium–High                       | Known image or document types could use explicit Maple ingestion paths. Arbitrary blobs have no generic model-facing representation and need type, decoding, size, staging, persistence, and rejection rules.                                                                                                                                                                                                                                                                                                                                               |
 | Resource links                             | No              | Medium–High                       | Supportable with policy work, and currently a baseline ACP v1 gap because resource links have no opt-out capability. Local and remote links need separate scheme, root, symlink, size, encoding, permission, and provenance rules so prompt ingress cannot bypass Maple's filesystem/web controls. Goose's private helper only performs an unbounded local `file://` text read, which Maple should not copy literally.                                                                                                                                      |
 | Arbitrary ACP-provided MCP servers         | No              | High                              | Technically supportable, but production-safe support expands a code-execution and secret boundary. Maple must validate client-supplied commands, URLs, headers, and environments; define authorization and name-collision rules; attach them transiently without persisting secrets; and guarantee per-session process cleanup across close, disconnect, crash, and Flatpak constraints. Generic stdio MCP is an ACP v1 baseline, so the current Buzz-only adaptation is a real conformance gap.                                                            |
-| Goose/Buzz native steering                 | No              | Medium code; high coupling        | Supportable but intentionally non-standard. Buzz uses `_goose/unstable/session/steer`, not an ACP v1 method. Goose's underlying `Agent::steer` queue is public; Maple needs an active-agent/run facade, `expectedRunId` validation, correlation updates, and prompt-end/cancel race tests. Buzz's cancel-and-merge fallback means this is not required for the tested flow, and adopting it would couple Maple to an unstable extension.                                                                                                                    |
+| Goose/Buzz native steering                 | No              | Medium code; high coupling        | Supportable but intentionally non-standard. Buzz uses `_goose/unstable/session/steer`, not an ACP v1 method. Maple Desktop owns a staged FIFO and sequential `Agent::reply` pump for send-while-running; it does not call Goose `steer`. ACP still rejects a second prompt and relies on Buzz's cancel-and-merge fallback; adding the unstable wire method would couple the adapter to a Goose-specific extension.                                                                                                                    |
 
 This is parity for the tested Maple task path, not parity with Goose's complete ACP implementation.
 
@@ -125,6 +125,8 @@ The refactor exposes a transport-neutral Maple service around the existing embed
 - ensure the account-scoped runtime exists;
 - create and delete a Maple task;
 - send and cancel a run;
+- stage a Desktop follow-up onto Maple's per-task FIFO and promote it with a later sequential `Agent::reply` on the same outer run; Stop cancels only the live Goose turn and leaves staged chips; X drops a chip; pencil edits a chip in place; an open edit holds leftover promotion until save or discard; Discard leaves that chip unchanged; a later Send flushes leftover chips plus any composer draft;
+- keep Desktop Stop from racing a follow-up send: in-flight composer sends are cancelled, and Send stays locked until the cancelled run settles;
 - consume an isolated, bounded event stream for one exact run;
 - receive typed permission requests and resolve them through an opaque responder bound to that exact account, task, and run;
 - observe a retained terminal result when a run stream closes normally; and