Verify mutation-testing result is reproducible, not stale

Author: czhao-dev

docs/architecture.md

@@ -527,19 +527,36 @@ alone. Filtered down to the fast, in-memory rule/algorithm fixture tests
 (`MissingOverrideRule`, `RedundantMoveReturnRule`, `UseAfterMoveRule`,
 `UnbalancedLockRule`, `UncheckedNullResultRule`, `ExpensiveCopyRule`,
 `LockOrderInversionRule`, `SCC`, `WorklistDataflowEngine`), a real run
-found 69 mutants (mull only generates mutants for lines the running tests
-actually cover) and killed 27 of them (39%). Of the 42 survivors, 24 are
+found 69 mutants and killed 27 of them (39%). Of the 42 survivors, 24 are
 in files whose *own* dedicated tests were excluded from this run for the
 memory reason above (`AnalysisDriver.cpp`: 11, `SuppressionState.cpp`: 5,
 `SarifFormatter.cpp`: 3, `Baseline.cpp`: 2, plus one each in
 `IncrementalCache.cpp`/`RuleFrontendAction.cpp`/`ToolchainDefaults.cpp`)
--- not a real gap, just this run's scope. The other 18, in files whose
-tests *were* included, are genuine: e.g. `LockOrderInversionRule.cpp`'s
-cycle-reconstruction loop and its `component.size() > 1` cycle/non-cycle
-boundary (8 survivors total), `UseAfterMoveRule.cpp`'s assignment-operator
-detection (3), and `SCC.cpp`'s shortest-path tie-breaking (2) -- concrete,
-file-and-line leads for future fixture work, not chased down further in
-this session.
+-- not a real gap, just this run's scope: none of the 34 selected tests
+call into those files at all, so no mutant there could ever be killed by
+this run regardless of how well-tested they are elsewhere. The other 18,
+in files whose tests *were* included, are genuine: e.g.
+`LockOrderInversionRule.cpp`'s cycle-reconstruction loop and its
+`component.size() > 1` cycle/non-cycle boundary (8 survivors total),
+`UseAfterMoveRule.cpp`'s assignment-operator detection (3), and
+`SCC.cpp`'s shortest-path tie-breaking (2) -- concrete, file-and-line
+leads for future fixture work, not chased down further in this session.
+
+**This exact result (69/27/42/39%, identical file-by-file breakdown) was
+independently reproduced on a second, completely fresh VM and build
+directory**, with the `--gtest_filter` applied from the very first mull
+invocation rather than after an earlier unfiltered attempt -- ruling out
+the otherwise-plausible concern that the first run's numbers were an
+artifact of coverage state left over from the unfiltered `--dry-run` that
+OOM'd before the CMake target scoping fix. `--debug-coverage` didn't
+produce clean enough output in this environment (missing shared-library
+warnings even after pointing `--ld-search-path` at the right directory)
+to pin down the *exact* mechanism by which mull decides a line in an
+excluded-tests file like `AnalysisDriver.cpp` is mutation-worthy at all;
+what's verified is that the result is deterministic and reproducible
+across independent runs, not session-contaminated -- the number is real,
+even without a fully traced explanation of mull's internal coverage
+bookkeeping.
 
 ## Build