shim: hold the acquire cadence at the cap period
What this fixes
The ICD shim's frame cap scheduled the next acquire at max(prev, now) + period. The condvar wait for prev always returns a hair after the deadline, so now won every frame and that overshoot was added to every period: the cap ran below its target by the wake-up latency per frame, and by more on a loaded or throttled device.
next_acquire_after now steps prev + period while the guest keeps up, and only re-bases on now once the guest is a whole period behind (no debt out of a stall). The two existing cases in the unit test are unchanged by the new rule; a third covers the overshoot.
Verification
Odin 3 (8 Elite, panel at 60 Hz), JT's stack (app #2283 + active-refresh report, payload 20261030.2) with only the ICD swapped, Dave the Diver title menu (renders above 60 uncapped), cap 60, two 30 s windows each:
| ICD | commits/s | mean interval |
|---|---|---|
| shipped 20261030.2 | 59.78 | 16.729 ms |
| this PR | 60.00 | 16.667 ms |
The displayed rate from dumpsys SurfaceFlinger --latency stays at 59.4–59.8 in both: a handful of presents per 30 s still take two vsyncs downstream, which this change does not address.
Scope: 24 lines in icd_shim/src/scanout.rs. JT's #32 does not touch icd_shim/, so this applies identically on master or on fix/gamescope-resolution-scanout; it was tested on the latter's payload.