[P2] Make recording sound preference changes reach the active recording cue

The recording sound toggle is evaluated only when the pipeline is built at launch. Turning it off leaves the existing audible cue enabled; turning it on after a silent launch leaves the existing SilentCue in place. The preference is saved and displayed, but does not control subsequent recordings until relaunch.

Evidence

Reviewed main 5c310667cd35c44abd8bbd26c19b0905471287b4. This is a source-path finding; no full-app audio playback reproduction is claimed.

• Sources/Uttrflow/AppDelegate.swift:535 chooses between SoundPlayingRecordingCue(player: SystemSoundPlayer()) and SilentCue() using the startup settings. The same instance is supplied to the capture engine and dictation controller.
• buildPipeline() is called at launch, and Sources/Uttrflow/AppDelegate.swift:1708 does not rebuild or update the cue when playsSoundWhenRecordingStarts changes.
• Both the capture engine and controller retain the cue in private let properties.
• Sources/UttrflowAudio/RecordingCue.swift:46 already supports a soundsEnabled closure read on each cue, but app construction omits that argument, leaving its constant true default. A silent launch instead constructs a cue that can never become audible.

Reproduction to cover

Launch with sound enabled, turn it off in Settings, and start another recording: the retained audible cue still plays. Also launch with sound disabled and turn it on: the retained silent cue still does nothing. Relaunch applies the saved selection.

Acceptance criteria

Make the existing recording path observe preference changes safely, using a synchronized preference source or an equivalent mechanism. Do not rebuild a running audio pipeline merely to toggle a sound. Test enabled-to-disabled and disabled-to-enabled transitions through application wiring with a recording sound player; also preserve the existing rule that a stop sound is only owed after a start actually played, including a change during a recording.

The source-reference check in DeadSwitchTests cannot detect this because the preference is read at startup. A callback-only Settings test also cannot prove the active cue changed.

Checked open and closed issues and open PRs. #168 concerns cue contamination of captured audio; this issue concerns whether the sound preference reaches the active cue.

Start with Sources/Uttrflow/AppDelegate.swift buildPipeline wiring and Sources/UttrflowAudio/RecordingCue.swift, then inspect how the capture engine and dictation controller retain the cue. Trace the preference source and existing DeadSwitchTests before adding coverage for both preference transitions, including a change during recording. Done means the active cue follows changes without rebuilding the pipeline and preserves the existing stop-sound rule.