Streaming-path parity for gpt-4o-audio: surface `delta.audio` (follow-up to #517)

Context / follow-up to #517

#517 surfaced gpt-4o-audio's message.audio on the non-stream /v1/chat/completions response. The streaming path still drops audio:

• OpenAiStreamDelta (crates/aisix-provider-openai/src/wire.rs) does not model audio.
• ChatDelta has no extra passthrough.
• RenderedDelta (crates/aisix-proxy/src/render.rs) has no audio/extra.

OpenAI streams gpt-4o-audio output via choices[].delta.audio ({ id?, data?, transcript?, expires_at? } incremental chunks). With the streaming structs not modeling it, a customer streaming a gpt-4o-audio response gets no audio deltas.

This is the same non-stream-vs-stream split as reasoning (#466 non-stream → #502 streaming parity).

Ask

Surface delta.audio on the streaming path: model it on OpenAiStreamDelta, carry it through ChatDelta (likely via an extra flatten mirroring the message-level approach), and emit it on RenderedDelta so streamed gpt-4o-audio audio reaches the client.

Verification

• Mock-parity: extend the mock to stream delta.audio chunks and assert the gateway forwards them.
• Real-chain: a streaming variant of the AISIX-Cloud PR-K (#677) gpt-4o-audio spec.

Refs

• non-stream fix: #517
• product issue: api7/AISIX-Cloud#684

Start with OpenAiStreamDelta in crates/aisix-provider-openai/src/wire.rs, then trace ChatDelta and RenderedDelta in crates/aisix-proxy/src/render.rs alongside the non-stream fix in #517. Extend the mock-parity coverage and the streaming AISIX-Cloud spec so incremental delta.audio chunks are forwarded to the client.