Description

When a conductor session completes a task and enters waiting state, subsequent messages sent via session send --wait return the previous (stale) response instead of the new one.

Steps to Reproduce

1. Set up a conductor session with Telegram bridge
2. Send the conductor a task that takes some time (e.g. write files, research task)
3. Wait for the conductor to finish — session transitions to waiting
4. Send a new message via Telegram (which calls agent-deck session send --wait)
5. Observe: bridge returns the response from step 2, not the response to step 4
6. Send another message — same stale response again, every time

Expected Behavior

session send --wait should return the response to the message that was just sent.

Actual Behavior

session send --wait returns the last persisted session output — the previous response — regardless of how many new messages are sent.

The ~20 second delay suggests session send --wait IS detecting the running → waiting transition correctly, but session output reads the response boundary incorrectly and returns the cached prior response.

Bridge Log Evidence

[INFO] User message -> [default]: what are the names of the idle sessions?
[INFO] Conductor [default] response: All 11 files written to `~/dev/ai/agent-deck-docs/`...

[INFO] User message -> [default]: why are you showing me the content of the conductor session?
[INFO] Conductor [default] response: All 11 files written to `~/dev/ai/agent-deck-docs/`...

Every Telegram message gets the same stale response — the last thing the conductor output before entering waiting state.

Environment

• agent-deck version: v0.26.4
• OS: macOS (darwin/arm64)
• Setup: Conductor session + Telegram bridge, session send --wait --timeout 300s -q

Workaround

None currently. Messages reach the conductor correctly but responses do not flow back through the bridge.