v0.20.5: the wheel learns to coast

getevent settled what the wheel can and can't tell us: och1970_holl_key
advertises KEY_UP and KEY_DOWN and nothing else -- no REL_WHEEL, no
resolution, because the och1970 is a Hall latch the driver quantises into
clicks. There is no sub-detent position to read without a kernel driver
change, so all the nuance has to come from *when* the detents arrive.

So a detent is now an impulse into a velocity rather than a jump. The list
coasts and eases out, and an impulse is worth up to 8x more when detents come
30 ms apart than when they come 220 ms apart -- squared, so the gain stays out
of the way while you're hunting for one row. Measured on the device: one
unhurried detent moves about half a row, twelve fast ones move forty-odd.
Turning back the other way kills the coast first, so a correction bites
instead of fighting the glide.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SKXUgsBBwe3qaHEjeV8ubP

andtunes/TASKS.md

@@ -29,6 +29,13 @@ each lands in is decided when it starts.
   row would be 4.4 mm tall. Do not "fix" this by changing the device density —
   trav likes it where it is.
 - Android 13 / API 33, `gsi_r1-userdebug`, arm64-v8a, 65 GB free.
+- **The wheel can only ever give us detents.** `getevent -pl` (2026-09-14):
+  `och1970_holl_key` advertises `KEY (0001): KEY_UP KEY_DOWN` and *nothing
+  else* — no `EV_REL`/`REL_WHEEL`, no `EV_ABS`, no resolution. The `och1970`
+  is a Hall latch, so the driver quantises the magnet into clicks and hands
+  userspace one key press each. There is no sub-detent position to read
+  without a kernel driver change, so every bit of nuance has to be derived
+  from the *timing* between detents (see `WheelScroll`).
 - Scroll wheel = input device `och1970_holl_key` → **KEY_UP / KEY_DOWN**,
   mapped by the stock `Generic.kl` (checked 2026-09-11 via `dumpsys input`)
   to **`KEYCODE_DPAD_UP` / `DPAD_DOWN`** — not volume. Side/PTT button sits