[UX] Stop/Seek/Volume controls silently no-op when audio unavailable — align feedback with TogglePlayPause

[lqdev]

[UX] Stop/Seek/Volume controls silently no-op when audio is unavailable — align feedback with TogglePlayPause

Summary

When audio hardware init fails (audio_command_tx is None), TogglePlayPause (fixed in #171 / PR #172) now shows "Audio playback not available on this system". However, the remaining audio controls still silently no-op in the same situation:

Action	Current behaviour (audio None)
TogglePlayPause (S-P)	✅ Shows error (fixed in #171)
StopPlayback	❌ Silent no-op
SeekForward (C-Right)	❌ Silent no-op
SeekBackward (C-Left)	❌ Silent no-op
VolumeUp (+)	❌ Silent no-op
VolumeDown (-)	❌ Silent no-op

This inconsistency was noted in the code review for PR #172 (comment by copilot-pull-request-reviewer).

Background

The original design was to silently no-op all controls when audio init fails, to avoid spamming messages. Now that TogglePlayPause shows an error, the user expectation is that feedback is available when a key does nothing.

Decision needed

Two options:

• All show the error — consistent; user always knows why a keypress does nothing
• All silently no-op — less noise for seek/volume during normal non-audio use (e.g. headless server)

The TogglePlayPause change in #171 sets a precedent for showing the error. The question is whether Stop/Seek/Volume should follow suit.

Note: the error string is already centralised in crate::constants::audio::UNAVAILABLE_ERROR (added in PR #172).

Files to modify

src/ui/app.rs — the StopPlayback, SeekForward, SeekBackward, VolumeUp, VolumeDown arms in handle_action() (~lines 1384–1417)

Acceptance criteria

• All 6 playback actions behave consistently when audio_command_tx is None
• Unit tests cover the chosen behaviour for at least Stop and VolumeUp
• No regressions in existing playback tests
• cargo clippy -- -D warnings passes
• cargo fmt --check passes

Deferred from PR #172 — see copilot-pull-request-reviewer comment on that PR.