fix: serialize PiVoice RPC turns

[0Downtime]

Summary

• serialize each complete PiVoice RPC transaction (new_session -> prompt -> agent_end)
• correlate new_session acknowledgements by request ID
• surface matching reset failures instead of treating every reset response as success
• add deterministic regressions for overlapping turns, stale acknowledgements, and rejected resets

Why

PiVoiceLLM owns one long-lived PiClient and one response queue, while a xiaozhi connection uses a five-worker ThreadPoolExecutor and submits conn.chat jobs asynchronously. Two overlapping turns could therefore read from the same ordered Pi RPC stream, allowing one caller to consume another caller's frames.

The reset path also accepted the first new_session response regardless of request ID or success. A stale failed response could complete the reset early and leave the correct acknowledgement queued for the next operation.

A deterministic regression run against unmodified main reproduced the overlap (second turn must wait: two active prompts instead of one). The same test passes with this lock.

Impact

Concurrent or rapidly interrupted voice turns now wait for the active Pi transaction to reach agent_end. Reset acknowledgements cannot be confused with stale responses, and explicit Pi reset failures are logged through the provider's existing fallback path.

Validation

• ruff check .
• bridge/Pi Python suite: 164 passed, 11 subtests passed
• dotty-behaviour suite: 231 passed
• combined coverage: 70.10% (56% required)
• PiVoice unit suite: 28 passed across 20 consecutive runs
• git diff --check

No live-device claim is made; this PR validates the reachable race with a deterministic concurrency harness.

Prepared with OpenAI Codex assistance and reviewed by the contributor before submission.