Hand a group reply on after the owner allows it to be shown

[Bartok9]

What this changes

Fixes #715. A group reply held until its owner allowed it to be shown was written into the transcript and then stopped, so an @Peer it named was never handed on. Allowing it now calls the same relay the immediate path uses, including the chain stored on the waiting row.

Where it runs

• New state that outlives a request? None. The waiting row already stores the chain.
• What happens on the second replica? The resume still reads that row from Postgres and offers the next turn on the shared work queue.
• Anything serialised? No new write race. Relay offers are keyed by the reply row id, as they already are.
• Anything fanned out to a browser? No new fan-out.
• New listener, port, or schedule? None.

Boundary and audit

• Every acting call still goes through the gateway: resolve, decide, audit, then act.
• New refusals and new failures each write a row. A refused hop still writes agent.handoff_refused, as the immediate path does.
• Nothing new is trusted from the client that the server can resolve itself.

Changelog

• A line in CHANGELOG.md under Unreleased.

Proof

bun test server/tests/group-conversations.integration.test.ts -t "held for the owner's permission" — the new case expects no agent.handoff_offered while the reply is held, then one offer and the peer's reply after the owner allows it.