### System details

Google Pixelbook (Eve, 2017), Core i5-7Y57, Omarchy 4.0.4, linux-omarchy 7.2.5-3. `bin/omarchy-audio-output-volume` is unchanged on quattro.

### What's wrong?

Holding volume up or down moves the volume much less than the number of key repeats. Each repeat starts a new `omarchy-audio-output-volume`, and they overlap: each run reads the current volume with `pactl`, adds 5% and writes it back, so overlapping runs read the same value and overwrite each other.

Reproduce with 10 overlapping presses 25 ms apart, which is what a held key does at `repeat_rate = 40`:

```
sink=$(omarchy-audio-output-sink)
pactl set-sink-volume "$sink" 20%
for i in $(seq 10); do omarchy-audio-output-volume raise & sleep 0.025; done; wait
pactl get-sink-volume "$sink"
```

Expected 70%. In three runs I got 40%, 35% and 40%: only 3-4 of 10 steps applied. Each run takes 0.4-0.7 s on this CPU (it resolves the sink, reads the volume, sets mute and volume, reads it again and starts `omarchy-osd`), so a held key has many runs in flight. A faster machine narrows the window but the race is still there.

A fix would be to serialize the read-modify-write with `flock`, or skip a repeat while the previous run is still going (`flock -n`), which also stops OSD calls piling up. A relative `wpctl set-volume -l 1.0 <id> 5%+` alone isn't enough: it's also read-modify-write inside wpctl, and I still lost a step in 10 with it.

#14683 sends the bar wheel and slider through this script too, which makes this path hotter. There are already three open PRs touching the script (#13405, #14683, #14813), so I didn't want to open a fourth without asking first. Happy to send one if useful.

AI disclosure: I found and measured this with Claude Code (Opus 5.5) and checked the results myself.