[DeusData]

Smart CI: a build may drop the suites only some runners register

Since TEST_IMPACT_MODE=gate (2026-10-17 22:10Z), a PR whose selection gets narrowed fails its x86 Linux test leg before any test runs:

FAIL: the test selection names suites this build does not register: coverage_setup_success coverage_setup_uncertain

Seen on #2679 and #2680. Only that leg consumes a selection; every other leg runs every test, so their results stand.

Cause

The selection comes from the coverage runner's map. tests/test_main.c registers four suites only under #if defined(CBM_TEST_COVERAGE) && !defined(_WIN32). scripts/run-tests-parallel.sh tolerates a selected suite the build lacks only when optional-suites.txt names it, and selection.py lists a suite there only when the answer marks it whole with CONDITIONAL. The model recorded a condition around a RUN_TEST registration, but not around the runner's RUN_SELECTED_SUITE, so these suites reached the leg as required. A real answer for #2679's head showed it: of the four, only coverage_children (whose own registrations are conditional) carried CONDITIONAL.

Fix

• cbm_test_runner_suite_t.conditional: every site that registers the suite sits under a preprocessor condition. A suite also registered outside any condition runs in every build and keeps the strict contract.
• After every whole-suite path (setup unknown/hit, triggers, inventory, rejected artifact) and the per-test path, a selected suite whose runner registration is conditional runs whole with CONDITIONAL. selection.py then lists it as optional, and a build without it drops it with a notice, exactly as its full run never runs it. The leg's guard is unchanged: a selected suite that no condition explains still fails the run.

Verification

• RED first: with the two .c changes reverted, test_selection_conditionally_registered_suite_is_conditional_on_every_path (seven selection paths, plus an unconditional control) and test_model_marks_runner_suites_registered_under_a_condition fail on their assertions; with them, test_impact passes 89/89.
• Real input: the fixed engine on fix(python): resolve a base class spelled through a root-binding import #2679's head against 354ccecb marks all four coverage suites CONDITIONAL (before: one), and selection.py's conditional_suites lists all four as optional (before: coverage_children only).
• Affected suites green (the test_impact family, runner_isolation).
• cppcheck 2.20, clang-format, the contract steps (scripts/test.sh --contracts-only) and the security audit are clean.

After the merge

A rerun of an affected PR replays its frozen merge commit, and select-tests builds its engine from that checkout, so it would rerun the old engine. Affected PRs need a new merge commit: merge main into the branch, or push again.

The diagnosis and the fix come from the graph-quality session, which found it independently; this PR carries their commit unchanged, plus a fixture correction (the selection test's coverage map did not parse).