buzz-acp: stream-channel @mentions can be stored and visible in feed, yet never traverse steer/wake path for a subscribed managed agent

### Summary

A managed `buzz-acp` agent can be subscribed to a normal stream channel while an owner's `@mention` is stored and returned by the message and mention-feed commands. The running agent session still does not enter the steer or wake path.

The affected channel appears in the active `buzz-acp` subscription log. Comparable mentions in a second subscribed stream channel do reach the steer path.

### Environment

- Buzz Desktop managed agent using `buzz-acp`
- ACP agent runtime on Linux
- Mention subscription mode with owner mentions enabled
- Relay address and machine-specific settings omitted from this public report

### Channels

- Affected stream channel: ``
- Working control stream channel: ``
- Channel identifiers omitted

### What was verified

1. The affected channel is a stream channel.
2. The agent is a member of the affected channel.
3. The active `buzz-acp` log records a subscription to the affected channel.
4. The log also records a subscription to the control channel.
5. Owner mentions in the affected channel are stored on the relay and returned by the message command.
6. The mention-feed command also returns those mentions.
7. Comparable owner mentions in the control channel trigger steer handling.
8. The affected-channel mentions produce no equivalent steer or wake log entries.

### Reproduction

1. Start a managed agent subscribed to two stream channels.
2. Send an explicit owner `@mention` in the affected channel.
3. Confirm that the message and mention-feed commands return the event.
4. Observe that the running agent does not wake or steer.
5. Send a comparable owner `@mention` in the control channel.
6. Observe that the agent wakes and the log records steer activity.

### Expected behavior

An explicit owner mention in any actively subscribed stream channel should enter the same wake and steer path.

### Actual behavior

The affected-channel mention is present at the relay and feed layers, but it never reaches the runtime wake and steer path. A comparable mention in the control channel works.

### Log evidence

The active log records subscriptions to both channel identifiers. For the control channel, it also records:

- `non-cancelling steer ack received`
- `ack=Ok(Err(ExpectedRunIdMissing))`
- `signal_fallback=true`
- `control signal sent to in-flight task`

Those wake and steer entries are absent for the affected-channel mentions.

### Scope

Membership, channel type, subscription state, relay storage, and mention-feed visibility were verified. The remaining failure appears between channel-scoped mention delivery and the runtime control-signal path.

### Related issues

- #2798 covers stale live runtime state after provider-backed configuration saves.
- #2698 covers dropped reply delivery despite runtime activity.
- #1743 covers mention delivery while an agent is offline.
- #2860 covers mention filtering in a different channel type.

### Suggested investigation

Trace channel-scoped event delivery through mention filtering and into the steer or control-signal path. Compare an affected subscribed stream channel with a working subscribed stream channel.

The exact relay, channel, and event identifiers were removed from this public report. I can provide them privately to maintainers if needed.