cpal output-stream errors are only logged; the engine never emits EngineEvent::Error or recovers

[forkwright]

Finding

The error callback passed to cpal::build_output_stream_raw only calls warn!. The error is never propagated to the engine: the broadcast channel never receives EngineEvent::Error, and the playback state (AtomicU8) stays STATE_PLAYING while the output stream is dead. The engine cannot detect the failure or restart the stream.

Evidence

crates/akouo-core/src/output/cpal.rs:178 — the error is logged and dropped:

warn!("audio stream error on '{device_name}': {err}");

EngineEvent::Error is defined at crates/akouo-core/src/engine.rs:54 for non-fatal errors but is never sent from the output path.

Why this matters

On Linux with PipeWire/ALSA — the likely audio stack on a sovereign handset — stream errors (device disconnect, server restart, suspend/resume) are routine. A swallowed error leaves the engine reporting STATE_PLAYING while emitting silence, with no event for the UI to pause, retry, or notify the user. The system asserts an activity it is not performing; under a counter-surveillance posture this deceptive state is itself a hazard, and there is no recovery path.

Desired correction

Pass a signalling channel (e.g. mpsc::Sender<OutputError>) into the error-callback closure so the DSP task can receive stream errors, broadcast EngineEvent::Error { message }, and transition the playback state to STATE_STOPPED (optionally attempting a stream rebuild).

Done when: a simulated cpal::StreamError raised in the error callback results in an EngineEvent::Error being broadcast and the playback state transitioning to stopped.