test: split the monolithic modules and measure what mutation testing actually says

[DLANSAMA]

Step 4 of 4. Stacked on #101.

The splits

Three modules held a third of the suite:

Was	Now
test_printer_commands.py (1333)	7 files by command surface
test_json_contracts.py (1031)	6 files + a shared json_contract_base.py
test_camera_cmd.py (927)	3 files (capture / command / output)

Verbatim moves. Each verified by diffing the collected test-id set before and after — identical in all three cases.

That check turned out to be necessary but not sufficient: it passed while two module-level helpers had been swept into the wrong file, because collection does not run anything. The full suite caught it. Both checks are worth keeping, and the PR keeps both.

Mutation testing: measured, not asserted

You asked me to fix a "high mutation survivor rate". I re-ran the baseline on a clean tree before changing anything, because the floor is CI-enforced and narrowing scope moves the score.

50.7% (killed 1061 / 2091), up from the documented 41.2%. Per-module numbers derived from the mutant sources and survivor list — they reconcile to the 50.7% total, so they are measured, not estimated:

Module	Score	vs documented
job/payload.py	69.4%	flat
netsafety.py	67.3%	+9
slicer/options.py	64.2%	+2
download/naming.py	61.7%	+6
job/predict.py	49.1%	+16
download/validation.py	40.3%	+10
slicer/output.py	21.8%	+0.8

Two findings worth your attention

1. The C.4 prediction did not pan out. docs/mutation-baseline.md claimed the hermetic Orca stub "should score materially higher" for slicer/output.py and asked for a re-run. Re-run: 21.8%, up 0.8 points. Line coverage went 79.8% → 92.7% while the mutation score did not move — the textbook signal that those tests execute _finalize_slice without constraining it. That module now holds 269 of the 1027 survivors (26%). The doc now says this instead of the optimistic prediction.

I did not try to fix it here. The honest options are to extract the pure decision logic out of _finalize_slice, or to stop counting it — both are production refactors, not test changes.

2. A real bug in the mutation runner. scripts/run_mutation_baseline.sh assigned MUTATION_SCORE_FLOOR without exporting it, so the score check — a child python process — never saw it and fell back to its own hardcoded default. A local run printed floor: 40% in its header and enforced a different number a few lines later. CI was unaffected only because the workflow sets the variable at job level.

Now exported, one value, and the child errors out rather than inventing a default.

Floor raised 40 → 48, just under the measured 50.7% — the same discipline already used for the coverage floor. The old 40 was set against 41.2% and had ~10 points of silent-drift room.

New boundary tests

tests/test_download_validation_boundary.py (32 tests) covers the _reject_* functions in download/validation.py — in the mutation scope, but with no direct tests. They were only reached incidentally through whole-command tests, which is exactly why mutants there survived: nothing asserted what they do.

It asserts observable outcomes (exit code, failed_step, machine-readable fields, credential redaction) and deliberately not error-message prose. Pinning message text couples tests to copy-editing; those mutants stay recorded as equivalent.

While writing them I found .exe is not on the refuse-list and text/html deliberately passes (it is the HTML-scrape path). Both are correct — the list names archive/document/image types, not a security allowlist — and are now documented in the tests.

Also

scripts/syntax_smoke.py now discovers scripts/ and tests/ instead of carrying a curated list that named two files this PR deletes — the same stale-parallel-list failure CLAUDE.md warns about. 87 → 157 files compiled.

Gates

1247 passed, 1 deselected     (was 1214 on #101)
coverage 87.1%
mutation 50.7% against the new floor of 48
ruff / ruff format / mypy / bandit / layers / drift-check                green
syntax / help / workflow / package-contents smokes                       green