Add end-to-end guarantee that agent event results are posted back to the source room

[Mr-Godot]

Bug / feature gap

When an agent is asked to post event/task results back into a Buzz room, the result can be absent from the room because the agent never receives the originating plain room message under the default mention-only configuration.

Observed behavior

The VECTOR service was configured with --channels <room> but no --subscribe flag, started in subscribe=Mentions, and therefore only accepted events containing a p tag for the agent. A normal room request did not trigger processing, so no result was posted back.

Impact

Requests made in a room can appear to be ignored, and users cannot rely on event results being posted in the same room.

Suggested fix

Add an end-to-end test: publish a plain room request, process it, and assert a result/reply event appears in that same channel. Also document/enforce the expected room delivery mode and preserve the source channel when posting results.

[maxitoon]

Revalidated alongside #4793 against current main (3c7f288c60d67df78577b237e27c3dfc8831aaa1). This issue now appears to contain two separate decisions:

1. Ingress: the plain room event never reaches ACP under the default mention-only configuration (ACP agent misses plain room messages when --channels is used without --subscribe #4793).
2. Successful-result publication and placement: current main still does not make same-room publication a harness-owned success invariant.

There is already substantial overlap, so I do not want to open another competing PR:

• fix(acp): publish adapter replies through harness fallback #5811 and draft Publish successful ACP replies #5820 both propose harness-side successful-response publication/fallback;
• fix(acp): keep top-level agent replies in channel [issue:#3825] #3908 and draft fix(acp): keep top-level agent replies in channel #3687 cover channel-root placement for top-level triggers;
• merged Verify ACP relay events before prompt routing #7010 and draft Verify ACP query events and bind channel routing #7012 harden event verification/routing, but do not settle successful-result ownership or placement.

Could a maintainer confirm the intended contract?

• Does the harness publish accumulated visible ACP output as a fallback, or must the external agent publish via buzz messages send?
• For a top-level channel trigger, should the result be a new channel-root event or a reply/thread rooted at the trigger?
• For a trigger already inside a thread, should the result remain in that existing thread?

After that decision, the non-duplicative E2E contract can assert: unmentioned selected-channel ingress, unchanged author restrictions, preserved source h tag, exactly one visible successful result, and the chosen root/thread placement.