oracle-gaps: a mutant's outcome can depend on its batch (setup-error in a full run, killed with --only) #53

Summary

In one onboarding run (klona, r20), two mutants were reported as setup-error in a full gap check, but a replay with --only killed both of them. A mutant's outcome must not depend on what else is in its batch: --only must give the result that the full run gives.

Evidence (unverified, from the r20 session)

• Repository: /tmp/oracle-validation/r20/codex-klona/repo. The notes are in oracles-feedback.md, beside the run log.
• Full run report 2026-11-12T23-35-42-301Z-3e2c4991: JSON mutants M21 and M22 were setup-error, with Spread syntax requires ...iterable[Symbol.iterator] to be a function. Production was unchanged and every baseline test passed.
• An isolated replay right afterwards, --only json.js:M21,json.js:M22 (report 2026-11-12T23-37-41-738Z-d866fd67), killed both under the law array slots.
• A full replay with the fork pool reproduced the setup errors (report 2026-11-12T23-38-22-238Z-fd6a91f0), so worker isolation did not change the result.
• In two later complete runs, the discrepancy did not recur.

Hypothesis (not confirmed)

The cause is global state carried from one copy to the next. Each copy resets its module registry and deletes the global names that the worker did not have at first (capture-setup.mjs). It does not undo changes to existing builtins, such as a property written on Array.prototype or Object.prototype. Klona's pollution-safety laws show that its mutants can write there. A polluting mutant that runs earlier in the same worker would then break a later copy's module load or setup (...iterable[Symbol.iterator]), which is reported as a setup-error that --only does not reproduce.

This is a different mechanism from the copy-path seed defect fixed in the follow-up PR for #48 (each copy seeded Math.random by its copy path). That defect affected every copy, so --only would show it too.

What a fix needs

• A witness in which a mutant's outcome changes with batch composition. It needs two mutants in one worker, in a known order, with the first writing to a builtin prototype. The runner's scheduling does not fix that order today, so a deterministic witness may need a way to pin a batch.
• Then, possibly: snapshot and restore builtin prototypes between copies, or run each copy that writes to them in a fresh worker.