fix(rumble): accept the v2 vibration valid-flag; bound stale buzz to 1.5 s

Two hardenings against runaway vibration (one Deck session buzzed on a
~2 s cadence): the DualSense output-report parse now also treats
valid_flag2 COMPATIBLE_VIBRATION2 (data[39] BIT2) as rumble-carrying —
a writer hardcoding the ≥2.24-firmware convention previously had its
rumble INCLUDING stops silently ignored, and a missed stop re-sends
stale nonzero state forever via the host's 500 ms refresh. And the
client's SDL rumble duration drops 5 s → 1.5 s: long enough that a
couple of lost 500 ms refreshes don't gap genuine rumble, short enough
that stale state dies on its own.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

crates/punktfunk-host/src/inject/proto/dualsense_proto.rs

@@ -397,7 +397,12 @@ pub fn parse_ds_output(pad: u8, data: &[u8], fb: &mut DsFeedback) {
                          // Motor rumble: high-frequency (small/right) motor at data[3], low-frequency (big/left) at
                          // data[4]. Scale 0..255 → 0..0xFFFF, same (low, high) convention as the uinput pad's mixer,
                          // and route to the universal rumble plane (0xCA).
-    if flag0 & 0x03 != 0 {
+                         // Writers on firmware ≥ 2.24 signal rumble via COMPATIBLE_VIBRATION2 in valid_flag2
+                         // (data[39] BIT2) instead of flag0 BIT0. Our feature report advertises 0x0154 so the
+                         // kernel and SDL stay on the flag0 convention, but a writer that hardcodes v2 would
+                         // otherwise have its rumble — including stops — silently ignored, and a missed stop
+                         // buzzes for the rest of the session (the 500 ms refresh re-sends stale state forever).
+    if flag0 & 0x03 != 0 || data[39] & 0x04 != 0 {
         let high = (data[3] as u16) << 8;
         let low = (data[4] as u16) << 8;
         fb.rumble = Some((low, high));