Swing the shake key's stick by the game's updates instead of the clock, two updates a side at any frame rate.

shake_stick picked the side from the time since the press, 67 ms a side (two frames at the game's 30 fps), so above
30 fps each side lasted more of the game's updates: 8 at 120 fps and 16 at 240, slower swings than the game reads at
its own rate. The side now comes from the game's present count, which frame_rate.c already kept for the flight
recorder and now gives through frame_step_presents, two presents a side. The press still swings for 800 ms of the
clock and a hold keeps it going, as before; while no present comes (a load) the stick keeps its side.

Not reproduced before the change (read from the code). The new tests/shake_key_check.py builds shake_stick from
input.c and passes (it fails 118 times on the old code); the runtime compile check and the -Wall comparison of
input.c and frame_rate.c show no new warnings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/building.md

@@ -756,6 +756,11 @@ files.
 A change to how a gamepad's axes are read (`runtime/input.c` `pad_axis`: an axis counts once it has been seen at rest)
 passes `python tests\pad_rest_check.py`, which builds that function with stand-ins for SDL. No game files.
 
+A change to the shake key (`runtime/input.c` `shake_stick`) passes `python tests\shake_key_check.py`, which builds that
+function with stand-ins for the clock and the game's present count: each side lasts two of the game's updates from 20
+to 240 fps, also with two reads an update, a press swings for 800 ms, a hold keeps swinging until its release, and a
+swing without presents keeps its side. No game files.
+
 A change to HD rumble's encoding or report schedule (`runtime/rumble_hd.c`: a vibration value as the bytes of a Switch
 controller's rumble report, and which reports are written when) passes `python tests\rumble_hd_check.py`, which builds
 that file alone: known values and the neutral one, the frequency and amplitude clamps (no amplitude step above the