🤖 tests: require-module-mock-restore known false negatives

[ThomasK33]

Problem

local/require-module-mock-restore (extended in #4652) is a flow-insensitive heuristic. Codex review found false negatives it does not model. None of these patterns occur in the repo today, and make lint is clean, so they are deferred rather than fixed:

1. Mutated restore lists. const entries = [["a", real]]; restoreModulesAfterSuite(entries); entries.length = 0; still counts "a" as restored.
2. if filters inside loops over specifier arrays. for (const p of P) if (p === "a") mock.module(p, …) resolves to every element of P, for both installs and restores.
3. Suites whose tests are all skipped. Bun evaluates the suite but never runs its afterEach, so a restore there does not execute.
4. A helper invoked both at load and from a scoped hook. Its installs are treated as load-time, so an earlier sibling suite's restore covers the later scoped invocation.
5. Helpers passed around dynamically (stored, passed to non-test APIs) are assumed to run where they are defined.

Fix direction

Only take this on if one of the patterns shows up in real tests. Each fix adds control-flow or per-call-site tracking to the rule. Prefer rewriting the test to the documented idioms (restoreModulesAfterSuite at file scope, or restores in afterAll/afterEach helpers) over growing the analysis.

Refs #4639, #4652.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $7.41

[linear-code]

MUX-255