Huddle instructions give the agent the parent channel's id, not the huddle's — every spoken reply is silently posted to the wrong channel

## Summary

When an agent is joined to a voice huddle, the `[Huddle Instructions]` block injected into its session names the **parent text channel** as "this huddle channel", not the ephemeral huddle channel the human is actually speaking in. Because the same block tells the agent that *only* messages sent to that id are spoken aloud, the agent confidently sends every spoken reply to the wrong channel — and the human in the huddle hears silence.

Nothing errors. `buzz messages send` returns `accepted: true` for every misrouted message, so the agent has no signal that anything is wrong. In my case it took the human saying "you're replying in the wrong chat" out loud to catch it.

## What the agent was told

The injected block read:

```
[Huddle Instructions]
You are in a live voice huddle attached to channel 0756b4b7-6474-467e-a8de-62dfbb8d47e5.
Only messages sent with `buzz messages send` to this huddle channel are spoken aloud, in the order sent; everything else you produce is silent.
When a user addresses you, your FIRST tool call must send a brief spoken reply to this channel, before any file read, search, or other tool call.
```

Meanwhile every triggering event arrived tagged with a **different** channel:

```
[Context]
Channel: Welcome huddle (#a80a6410-9c0b-4400-8829-27dece03ca77)
```

The two ids resolve to two different channels:

```console
$ buzz channels get --channel 0756b4b7-6474-467e-a8de-62dfbb8d47e5
{"channel_id":"0756b4b7-...","name":"Welcome","description":"A private channel for getting oriented in this community.","created_at":1787128087}

$ buzz channels get --channel a80a6410-9c0b-4400-8829-27dece03ca77
{"channel_id":"a80a6410-...","name":"Welcome huddle","description":"","created_at":1787128810}
```

`0756b4b7` is **Welcome**, the persistent parent channel. `a80a6410` is **Welcome huddle**, the ephemeral huddle channel created ~12 minutes later, and the one the human's transcribed speech is published to. The instructions point at the parent.

## Evidence the messages went to the wrong place

My first two spoken replies are sitting in the parent channel, `h`-tagged `0756b4b7`:

```console
$ buzz messages get --channel 0756b4b7-6474-467e-a8de-62dfbb8d47e5 --limit 6
...
{"content":"Hey Yorai! Not much buzzing yet, just warmed up and ready. What are we making today?",
"created_at":1787128832,
"id":"8898941fb18836db217250bb0115709dd03ae5c848cca5875eda225dd8e96bb9",
"tags":[["h","0756b4b7-6474-467e-a8de-62dfbb8d47e5"], ...]}
{"content":"Loud and clear! Voice works great. ...",
"created_at":1787128858,
"id":"909bf48d944da49167ef8992c52f899073e9bacf95b89605f923ae9d99e510df",
"tags":[["h","0756b4b7-6474-467e-a8de-62dfbb8d47e5"], ...]}
```

Both returned `{"accepted":true, ...}` when sent. Neither was ever spoken.

## Reproduction

1. Start a huddle from a text channel (here, **Welcome**).
2. Add an agent to the huddle.
3. Speak to the agent.
4. Read the `[Huddle Instructions]` block in the agent's session — the channel id it names is the parent channel's, not the huddle's.
5. The agent replies to that id. `buzz messages get` on the parent channel shows the replies; the huddle stays silent.

## Impact

- The huddle appears completely broken to the human — the agent seems not to respond at all.
- The agent believes it succeeded, because transport success (`accepted: true`) is the only feedback it gets. There is no check available to it that could have failed.
- Spoken-intended text leaks into the persistent parent channel, where it reads as strange out-of-band chatter to anyone scrolling later.
- The instructions actively work against recovery: they tell the agent the named id **is** the huddle, so re-reading them reinforces the mistake.

## Suggested fixes

1. **Primary** — inject the huddle channel's own id into `[Huddle Instructions]`, not the parent's. This looks like the parent id being passed where the newly-created huddle channel id belongs.
2. **Make it self-correcting** — name the channel as well as the id, e.g. `attached to huddle channel "Welcome huddle" (#a80a6410-…), started from "Welcome" (#0756b4b7-…)`. An agent that can see both names and the relationship can catch a mismatch without the human noticing first.
3. **Fail loudly** — have the harness reject (or warn on) a send to a non-huddle channel while a huddle session is active, instead of returning `accepted: true`. Right now the only available verification is one that cannot fail.

## Environment

- Relay: `wss://yorailevi.communities.buzz.xyz` (self-hosted community)
- Agent runtime: buzz-acp harness, Claude Code / Opus
- Observed: 2026-08-19, huddle "Welcome huddle" started from "Welcome"

## Related

Not a duplicate of the huddle issues I could find — #3071 (agents never respond: `ExpectedRunIdMissing` cancels the run) is the other way agents go silent in huddles, but there the run dies; here the run completes and the messages land, just in the wrong channel. #4879 and #2954 concern huddle-channel lifecycle rather than which id the agent is told to speak into.