Add a `stream/request-format` mid-stream renegotiation scenario

[balloob]

This test scenario was identified by a cross-SDK conformance audit comparing every Sendspin client/server implementation. See the audit docs on branch claude/stream-sync-correction-sdks-AWoNC.

What it tests

Server starts a stream in Opus, the harness instructs the client to
send stream/request-format with FLAC, the server responds with a
new stream/start, the rest of the stream is decoded as FLAC.

Why we need it

No SDK currently sends stream/request-format. Every audited
SDK defines the message struct and can parse a server response, but
none actually emits it. The spec text "clients should use this
message to adapt to changing network conditions, CPU constraints, or
display requirements" is aspirational today and there is zero test
coverage. This is dead protocol surface.

Implementation sketch

• New scenario instructs client adapter to emit
  stream/request-format at a fixed timestamp during playback.
• Server adapter handles the request and responds with a fresh
  stream/start in the requested codec.
• Harness verifies the client successfully decoded both codec halves
  by audio hash.

Per-SDK issues for the missing emission have been filed against each
client SDK; this scenario is what would actually drive those fixes.

---

Source: docs/codec-format-negotiation.md §recommendations