buzz-acp queue mode batches independent requests and destroys per-event reply identity

## Summary

`BUZZ_ACP_MULTIPLE_EVENT_HANDLING=queue` does not preserve one inbound event → one ACP turn → one reply. The queue drains multiple pending channel events into one batch, so independent requests lose their individual audit identity.

## Tested versions

- `block/buzz@87b3fcd3c0131683569dd4268b099d18b25dcd5e`
- community Hermes fork `amanning3390/buzz@9a6f45792c02cd6d241e30a261e87468a4738227`
- BYOH base: `95fdf978800982389b120c66ff5e766d785419c7`
- ACP agent: profile-backed `hermes-agent 0.19.0`

The test was fully synthetic and isolated. It used no production data or credentials.

## Reproduction

1. Start `buzz-acp` with:

```text
BUZZ_ACP_MULTIPLE_EVENT_HANDLING=queue
```

2. Send six independent @mentions to one shared channel, one second apart.
3. Wait for the queue to drain and inspect request/reply events.

## Observed

After 542.3 seconds:

```text
requests: 6
responses: 2
```

- Response 1 handled the first request.
- Response 2 merged the remaining five requests into one ACP prompt/reply.
- FIFO ordering was retained, but one-request/one-response audit identity was not.

The source behavior matches the result: `crates/buzz-acp/src/queue.rs` drains up to `MAX_BATCH_EVENTS` pending events from the channel into one `FlushBatch`; the current constant is 50.

Default `steer` mode was worse for the same six-event fixture: new events arrived before Hermes exposed an active run ID, Buzz logged `ExpectedRunIdMissing`, cancelled/superseded turns, and ultimately merged all six requests into one response.

## Expected

Queue mode needs a per-event policy for service/request workflows:

```text
BUZZ_ACP_BATCH_MODE=per-event|batch
BUZZ_ACP_MAX_BATCH_EVENTS=1
```

Under `per-event`:

- `flush_next()` pops exactly one queued event;
- one ACP prompt corresponds to one inbound event;
- completion/retry/dead-letter state is keyed by event ID;
- one failed event does not merge or block later events;
- the response is linked to the triggering event/thread;
- existing batch/digest behavior remains available explicitly.

## Acceptance test

- six mentions one second apart;
- six distinct ACP prompts;
- six distinct signed reply events;
- each reply linked to exactly one request;
- FIFO order preserved;
- failed request 3 retries without merging requests 4–6;
- restart recovery does not duplicate completed responses.

This is not merely response formatting. Current batching destroys the request/response pairing needed for coworker service, retries, attribution, and audit review.