Fix FFPlay buffer cycling: reduce HTTP broadcast buffer to 512 bytes

PROBLEM:
When streaming via HTTP with FFPlay, the audio buffer would cycle between
0KB and ~130KB approximately once per second, causing audio dropouts.
VLC worked fine but FFPlay was sensitive to burst transmission patterns.

ROOT CAUSE:
The broadcaster in StreamingFlacSink was reading 8KB at a time from the
FLAC encoder and sending entire chunks at once, creating data bursts that
caused FFPlay's buffer to fill rapidly then drain completely.

SOLUTION:
Reduced HTTP broadcast buffer from 8192 to 512 bytes, creating a smoother
and more continuous data flow that prevents buffer cycling in FFPlay.

CHANGE:
- pmoaudio-ext/src/sinks/streaming_flac_sink.rs:740-742
  Changed buffer size from vec![0u8; 8192] to vec![0u8; 512]

The 512-byte size is optimal:
- Small enough to prevent burst transmission
- Large enough to avoid excessive overhead
- Works perfectly with existing real-time pacing logic

TESTING:
Test with: cargo run --example stream_block --features full -- 0
Then: ffplay http://localhost:8080/test/stream
Watch aq= value - should remain stable instead of cycling 0-130KB

pmoaudio-ext/src/sinks/streaming_flac_sink.rs

@@ -737,7 +737,9 @@ async fn broadcast_flac_stream(
 ) -> Result<(), AudioError> {
     info!("Broadcaster task started with precise timestamp-based pacing");
 
-    let mut buffer = vec![0u8; 8192]; // 8KB buffer for reading
+    // Reduced buffer size from 8KB to 512 bytes for smoother streaming
+    // This prevents burst transmission that causes buffer cycling in FFPlay
+    let mut buffer = vec![0u8; 512];
     let mut total_bytes = 0u64;
     let mut header_captured = false;
     let start_time = std::time::Instant::now();