fix(mutation): date each scratch write with its own mtime second

[CameronBrooks11]

What

kindkit/mutation.py: gate gives every write of the scratch file a distinct whole-second mtime, applied with os.utime in _probe right after the write. A run starts at a random second between 2000-01-01 and 2020-01-01 UTC (_STAMP_RANGE, drawn with random.SystemRandom) and adds two per write (_STAMP_STEP). (Step and generator changed in the follow-up below.) The purge from #14 is unchanged and still runs.

A .pyc records the (mtime second, size) of the source it was compiled from. So a .pyc compiled from an earlier write of the scratch file fails validation wherever it is cached, including under a PYTHONPYCACHEPREFIX that the probe chose for itself and the purge cannot see. A copy of the source is a different file with its own mtime; see the follow-up.

• tests/test_mutation.py: new test_a_mutant_is_never_served_bytecode_the_purge_cannot_see. It drives the real gate with a probe that loads the scratch file in a child process with its own fixed PYTHONPYCACHEPREFIX. Nothing in the probe sets an mtime. There are 20 same-size mutants, alternating between detected (b..) and claimed equivalent (a..), so any write served the previous write's bytecode gets the other class's verdict. Two preconditions are asserted so the test cannot pass vacuously: bytecode exists in the probe's prefix, and the run was fast enough for writes to share a second.
• tools/mutation_gate.py: two new mutations. One drops the os.utime call; the other swaps itertools.count for itertools.repeat, giving every write the same stamp. One existing pattern ("the gate mutates the implementation in place") is updated for _probe's new argument. The gate reported it STALE until I updated it.
• README.md ("What a probe has to get right") and the gate / _purge_bytecode docstrings: what the kit now does, and what the probe still owns.

Why

This is the candidate fix recorded in #11's comments. A fixed private prefix is the case #14 left open, and this PR shows that case produces wrong verdicts without the probe pinning anything.

Testing

Red first, on main (bf716e3), with only the test added. Three consecutive runs:

$ uv run pytest -q tests/test_mutation.py -k bytecode_the_purge
E       AssertionError: assert () == ('b00', 'b01'...', 'b05', ...)
E       AssertionError: assert ('b09',) == ('b00', 'b01'...', 'b05', ...)
E       AssertionError: assert ('b09',) == ('b00', 'b01'...', 'b05', ...)

So on main, the gate killed 0 or 1 of 10 mutants that the suite detects. The same shape through a standalone script on main (10 pairs) gave 20 mutants in 0.31s: ok=False killed=0 survived=10 equiv=10 bogus=0.

After the fix:

$ for i in $(seq 20); do pytest -q tests/test_mutation.py -k bytecode_the_purge; done
20 x "1 passed"
$ just check
All checks passed!
$ just test
146 passed
$ just mutants        # in a throwaway detached worktree of this commit
  caught    the previous probe's bytecode is served to the next mutant
  caught    bytecode cached beside the scratch file is no longer purged
  caught    bytecode cached under the interpreter's prefix is no longer purged
  caught    a scratch write keeps the wall-clock mtime, so writes share a second
  caught    every scratch write in a run gets the same mtime
101 mutations, 101 caught, 0 survived, 0 broken

For each new mutation, and for the updated one, I applied it with the gate's hash-checked apply and ran its listed test on its own. Each exited 1, and each file restored to its original hash.

Follow-up (review)

1. Overclaim corrected. The README and docstrings said a stale .pyc fails validation "wherever it was cached ... or copied elsewhere". That holds only for bytecode compiled from the scratch file itself. A probe that copies or rewrites the source before importing it gives the copy a wall-clock mtime, so the stamp does nothing for it. The reviewer reproduced this with a copy to a fixed path plus a child with its own fixed prefix. "Bytecode or source copied anywhere else" is back in the README's list of what the probe owns.

2. 2-second filesystems. FAT and exFAT store mtimes in 2-second steps, so stamps 2k and 2k+1 can be stored equal. The stamps now step by 2 (_STAMP_STEP = 2). New test test_consecutive_scratch_writes_are_two_seconds_apart records the scratch file's mtime at each probe. It was red before the change: assert [1.0, 1.0, 1.0] == [2, 2, 2]. Gate mutation: _STAMP_STEP = 1.

3. Figure corrected. The range is 1_577_836_800 - 946_684_800 = 631,152,000 seconds (python3 -c "print(1_577_836_800 - 946_684_800)"). The previous body said 630,720,000, which was wrong.

4. random.SystemRandom() for the start. Before the change:

   • test_a_callers_random_generator_is_not_drawn_from failed with "the gate drew from the caller's random generator";
   • test_a_callers_random_seed_does_not_fix_the_stamps failed with assert 1419917831.0 != 1419917831.0, so two runs seeded the same way started on the same stamp.

   Gate mutation: SystemRandom().randrange reverted to random.randrange. Both listed tests exit 1 under it.

What the probe still owns (now listed in the README)

• a probe that sets the scratch file's mtime;
• a probe that copies or rewrites the source before importing it, and bytecode copied anywhere else;
• a filesystem whose mtimes are coarser than 2 seconds;
• an interpreter told to trust unchecked hash-based .pyc files;
• across runs: within a run each import recompiles over the previous .pyc. So a later run can inherit only the one .pyc an earlier run left for that path, and only if the later run's first write lands on that .pyc's exact stamp at the exact size. The start is drawn uniformly from 631,152,000 seconds; that odds figure is computed from the range, not measured.

#11's first acceptance bullet asks for a purge that removes nothing to be reported. This change makes such a purge harmless instead, which is why this PR says Refs.

Gates after the follow-up, with main (#21) merged in

$ just check
All checks passed!
$ just test
156 passed
$ just mutants        # throwaway detached worktree
  caught    a scratch write keeps the wall-clock mtime, so writes share a second
  caught    every scratch write in a run gets the same mtime
  caught    scratch writes are stamped one second apart, which FAT stores as equal
  caught    the first stamp comes from the caller's seedable random generator
111 mutations, 111 caught, 0 survived, 0 broken

For each new mutation, and for the updated repeat mutation, I applied it with the gate's hash-checked apply and ran each listed test on its own. All exited 1, and each file restored to its original hash.

After merging main with #19 (merge commit 21ebf67): just check all checks passed; just test 157 passed; just mutants (throwaway detached worktree) 112 mutations, 112 caught, 0 survived, 0 broken. CI green.

Refs #11