#494 Pin the keyboard-scan grace period in tape loader detection

[Fredrick Meunier]

Problem

Commit e52d195e (October 2026) made ROM-style keyboard scans stop the tape only after a bounded grace period (250 frames) and made recognised loader reads reset that grace, but added unit coverage only for the ula_read_is_keyboard_scan() detector itself - nothing pins the stop timing, the grace reset after a recognised loader read, or the unchanged ten-consecutive-read limit for non-loader reads.

Proposed change

loader_test_keyboard_scan_grace() in unittests/loader.c drives the real loader_detect_loader() entry point with a real machine and tape state: 250 frames of ROM-style keyboard-scan reads (CPL; AND 1f; RRA) never stop the tape while the grace counts down, the next keyboard-only read stops it exactly when the 250-frame grace expires, a recognised ROM-loader read resets the grace so a further 250 keyboard-only frames are again required, and non-loader reads with implausible counter timing still stop the tape after exactly ten consecutive reads. Test-only: loader.c and the build system are untouched; settings fastload is forced off during the test so tape_stop() cannot initialise the sound subsystem before the sound tests run; the MIC-off events tape_stop() schedules stay queued exactly like the existing tape_edge_unittest leaves them, and the next machine_select() resets the event stack before any later test could dispatch them.

Notes

• Test-only change: unittests/loader.c gains loader_test_keyboard_scan_grace(); loader.c and the build system are untouched.
• Validated with the null-ui build profile (bootstrap, configure, make, make check); the suite reports Final return value: 0 with the new test registered in loader_unittest().
• The grace constants are pinned by value (250 frames, 10 consecutive reads); changing either constant in loader.c makes the test fail, so the boundary is maintained deliberately.
• Mutation check: shortening the grace constant to 10 frames makes the new test fail at frame 10; restoring the constant makes the suite green again.
• No GUI or ROM-level claims: the test runs inside ./fuse --unittests with the null UI; interactive runtime was intentionally not exercised.

Validation

• The null-ui build profile (bootstrap, configure, make, make check) passed all four stages on the patched tree with zero warnings; the suite's final return value is 0. (passed)
• The new test discriminates: shortening the grace constant in loader.c makes it fail at frame 10, restoring the constant makes the suite green again. (passed)
• The change is exactly one tracked file (unittests/loader.c, +116 lines); loader.c and the build system are untouched. (passed)

Changed files

• unittests/loader.c

Repo-Assist-Effect: e8f9570abdad5267fc5ff1f51021eef1689df6ba44cc57553367453ca366153b

[Fredrick Meunier]

Applied in [abb1c5].