pipewire: write route volumes without volume step

[faithleysath]

Summary

Fix PipeWire route volume writes for devices that do not report SPA_PROP_volumeStep.

On these devices, volumeStep is parsed as -1. The previous logic only called PwDevice::setVolumes(...) from inside the volumeStep != -1 branch, so route-backed sink volume writes updated Quickshell's local mVolumes state but did not write the new volume to PipeWire.

This keeps the existing minimum-step filtering when a device reports volumeStep, and treats a missing step value as "no step threshold", allowing the route volume write to proceed.

Fixes #807

Testing

• just configure debug -DNO_PCH=ON -DBUILD_TESTING=ON
• just build
• git diff --check
• Tested locally against a Bluetooth sink (bluez_output.6C_5A_B5_EB_5E_8D.1) by writing Pipewire.defaultAudioSink.audio.volumes = [0.24, 0.24] from QML and verifying wpctl get-volume @DEFAULT_AUDIO_SINK@ changed to Volume: 0.24.

just lint-changed was not run because this local checkout does not have the required TIDYFOX environment variable configured.

[ozwaldorf]

Hitting this issue on my machine as well, worked around using wpctl on bluetooth devices for now.

The following github issues are all reporting this bug:

• Audio volume level does not change when bluetooth device is connected #325
• PwNodeAudio volume writes only update local state on Bluetooth sinks without volumeStep #807
• Pipewire binding not working correctly for *some* BT devices #857

[ozwaldorf]

Confirmed this patch is working for me, applied to the latest 0.3.0 quickshell release via nix and tested on my configuration

[nuknes]

hitting this on Arch with quickshell-git (0.3.1.r10, commit 2d3b3e9), Caelestia shell, HCH-RF02 (bluez5) as default sink

volume control is completely unresponsive on the BT sink; wpctl set-volume works fine on the same node

confirmed the root cause matches this PR: volumeStep parses as -1 for the bluez5 node, so PwDevice::setVolumes() is never called, only local mVolumes state updates