Stop CS8409 audio policy event loops

[farkas]

Problem

Two independent event-ordering issues affected the CS8409 user services:

1. cs8409-mixer.service was marked failed when WirePlumber had not selected a default source yet or PipeWire had not created cs8409_speakers. The mandatory ALSA mic controls had already succeeded.
2. cs8409-dsp-unity-lock.sh reacted to every PulseAudio event by launching pactl set-sink-volume. Each invocation created more client and sink events, retriggering the helper indefinitely.

The feedback loop generated 1,024 events in three seconds and sustained approximately 33% CPU in WirePlumber, 22% in PipeWire Pulse, and 20% in PipeWire.

Changes

• Keep both ALSA microphone commands mandatory.
• Make the timing-dependent default-source and DSP-sink commands non-fatal with systemd's ExecStart=- prefix.
• React only to new or changed sink events in the unity helper.
• Read cs8409_speakers first and write only when it is not already at 100%.

A real DSP sink volume change now produces at most one corrective write. Its resulting event performs a read, sees unity, and stops.

Validation

Validated on MacBookPro14,3 / PipeWire with the CS8409 filter graph active:

• bash -n pipewire/cs8409-dsp-unity-lock.sh
• git diff --check
• event rate fell from 1,024 to 25 events per three seconds
• WirePlumber, PipeWire Pulse, and PipeWire each measured 0% instantaneous CPU in two consecutive samples
• changing cs8409_speakers to 90% restored it to 100% / 0.00 dB within one second
• CS8409 DSP sink, four-channel hardware sink, and internal mic remained present
• mixer and DSP unity user services remained active

User-facing volume remains on the downstream four-channel hardware node; this helper only holds the DSP filter sink at unity as designed.