[mcmanussliam]

What and why

Fixes #2400. In Ocarina of Time on an M4, the game sat at 20 fps in places where it could hold 30. Two rules in nvn_fstep_next caused it:

• Stepping down was too strict. Going from 20 to 30 fps needed 30 frames in a row under the limit (28.3 ms), and one slower frame started the count again. Now a frame up to 8% over the limit (FSTEP_LEAK) takes one off the count instead. Frames further over still reset it, so a scene that can't hold 30 isn't tried more often.
• A failed probe could overshoot. When a try at 60 fps failed, the new frame rate came from one slow frame, so a single 45 ms frame could send it to 20 fps. Now it goes back to the rate it came from (probe_from).

Details: The frame step holds 20 fps where 30 fits.

Checked

• Tests: make -C dm/gfx/tests GAME=0400486024DEC000 t_fstep (84 pass; the two new behaviour tests fail on main); python3 -m unittest dm/tools/tests/test_docs.py (OK); dm/tools/lint_c.py tidy (no new findings)

• Games run: The Legend of Zelda: Ocarina of Time 0400486024DEC000 v131072, the Mac app with only dmhost swapped. Same route and settings (Dynamic resolution off), one run each (3.3 and 4.0 min):

  	main	this PR
  Time at 20 fps	13%	8%
  300-frame windows averaging 20 fps	2	0
  Drops to 20 fps that ended by stepping down to 30	1 of 6	3 of 4

• Devices and OS: Apple M4 (10-core GPU), macOS 27.0.1

• regress.py check --games: not run. Ocarina of Time is the only game I have, and regress.py needs --platform mac build folders. regress.py impact main..HEAD names Breath of the Wild, Tears of the Kingdom and Pokémon Scarlet, and Mario Kart World also uses the frame step. None of these were checked; a run from their owners would help, especially Breath of the Wild on an iPhone, which relies on the probes.

Docs

• The finding is in its reference entry and the game note, and python3 dm/tools/docs_symptoms.py was run
• A chain tool changed (not applicable)
• No game files, keys or data extracted from a game in the change or the attachments