Expose and verify TAS replay fast-forward speeds

[Alexbeav]

Expose visible TAS playback speed as python tools/tasreplays/tekken3.py run --speed 4|8|32|max. Previously the replay runner discarded inherited speed settings and could not hold the fast-forward key, and the runtime silently fell back to 4x for caps above 16.

PSX_FAST_FORWARD=1 selects the existing host fast-forward pacing/presentation path from startup. Extend its bounded range to 64x and record the selected cap in the replay manifest. Guest clocks, controller inputs, device timing and generated game/BIOS code are unchanged. Headless playback is already uncapped, so the CLI rejects a simultaneous speed override. Documentation distinguishes a requested ceiling from achieved throughput.

Validation:

• Native Windows UCRT player rebuilt successfully.
• Existing recipe and host-shortcut checks pass. Invalid caps and headless speed overrides fail before launch.
• Windows UCRT CI passed on the final head, including the new rejection test for older setup receipts.
• All four sequential cold-boot visible runs passed: 7,974 original inputs and all 8,399 RAM/clock fingerprints match. All final screenshots were inspected directly, show YOU WIN / FINAL 8.80, and have identical SHA-256 hashes.

Requested setting	Full verification	Native host seconds	Achieved real-time rate
4x	PASS	312.938	0.448x
8x	PASS	311.594	0.450x
32x	PASS	311.032	0.451x
max	PASS	311.047	0.451x

These runs prove determinism across the selected speed controls, not actual 4x–32x throughput. Full RAM verification was enabled. The process averaged roughly one busy CPU core during the uncapped sample; measured throughput remained about 0.45x. Guest time through return 8,399 was 140.142873 seconds in every run. Actual accelerated throughput still requires performance work.

The fixed tested native SHA-256 is 6df41fe25e0daa12fba7db0d167dca7d3f747574a284632ab517c8fd36a43301. The final follow-up changes only setup metadata, a pre-launch capability guard, its regression test and documentation: an older executable's setup receipt must be regenerated before selecting a speed, preventing silently ignored controls after a Git update. The runtime and runner used by the four completed replays are unchanged.

This PR targets the fork's tasreplays branch. The existing post-victory CDDA and cross-title qualification limits still apply.

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}