Allow local ACP providers (or an API) to post assistant messages into a thread after the turn has settled #28026

Use case

We run long-lived coding agents outside T3 and want each one visible as its own T3 thread on desktop, with status updates appearing as they happen (for example "tests passed", "PR opened", "blocked on a decision").
The updates originate outside any user prompt, so they need a way into the thread after the previous turn has finished.

What we tried (T3 v0.1.5)

We registered a small deterministic agent as an ACP Registry provider with source: local, on an isolated T3 instance, and checked the desktop UI and t3 thread show --json after each step.

1. A normal prompt was answered and shown, and the turn settled (end_turn; status completed, no active run).
2. After settlement, on the same session, the provider sent:
   • a plain session/update with agent_message_chunk;
   • a tool_call / tool_call_update followed by an agent_message_chunk;
   • a state_update running, an agent_message_chunk, then state_update idle.
3. None of these appeared in the thread, no new run was created, and the thread did not show as busy; the messages were dropped.
4. A later explicit prompt to the same provider process was answered immediately, so the provider was alive throughout.

Example late notification:

{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"<session>","update":{"sessionUpdate":"agent_message_chunk","content":{"type":"text","text":"Worker tests passed after the previous turn completed.\n"}}}}

Why (from the v0.1.5 source)

• Post-settle continuation in packages/provider-acp/src/server/adapter.ts is gated on the adapter flavor's enablePostSettleContinuation (around L1366).
• The ACP Registry flavor in packages/provider-acp-registry/src/server/adapter.ts (around L211-290) does not set it for generic local providers, and there is no setting in packages/provider-acp-registry/src/settings.ts to enable it.
• With continuation disabled, late output is not buffered (around L4262) and an already-finalized context returns early (around L4820, L6982).

Request

Either of these would cover it:

1. A provider setting (for example on source: local entries) that enables post-settle continuation, so an ACP provider can add assistant output to its thread after a turn settles, with the thread returning to idle afterwards.
2. An authenticated API, MCP tool or CLI command to append an assistant message to an existing thread without starting a provider turn, for example t3 thread append <thread> --role assistant <text>.

Our current workaround is to send each update as a user prompt that the deterministic provider echoes back. That works, but every update appears as a prompt-and-reply pair, which doubles the clutter.

Happy to test a build or help with a PR if a direction is preferred.