fix(scan): require explicit trust for .wardline/judged.yaml suppressions

[tachyon-beep]

Motivation

• Repository-controlled .wardline/judged.yaml was being applied by scan before gating, allowing untrusted judged records to suppress real defects and clear --fail-on in CI.
• The change aims to preserve the local trusted workflow (where judged suppressions are useful) while protecting the CI/trust boundary by default.

Description

• Make run_scan() ignore load_judged(root / ".wardline" / "judged.yaml") unless the caller sets trust_judged_suppressions=True (default False), so judged suppressions are opt-in for trusted checkouts via an explicit operator decision.
• Add a new CLI option --trust-judged-suppressions to wardline scan and thread it through the initial scan and the post-autofix rescan so local/trusted workflows are preserved when requested.
• Keep judge workflows unchanged for triage/persist paths by calling run_scan(..., trust_judged_suppressions=True) from run_judge() so judge --write and triage flows still consult/write judged records as expected.
• Strengthen load_judged() to require a verdict field and reject any record where verdict != "FALSE_POSITIVE" to avoid accepting forged/non-FP entries as suppressions.
• Update unit tests to reflect the trust-boundary semantics and to add coverage for non-FALSE_POSITIVE judged records.

Testing

• Ran byte-compile checks with PYTHONPATH=src python -m py_compile ... on the modified modules, which succeeded.
• Ran style/lint checks with uv run ruff check ..., which passed.
• Attempted targeted pytest runs (e.g. uv run --extra scanner pytest tests/unit/core/test_judged.py tests/unit/cli/test_cli.py::test_judge_write_then_scan_gate_requires_trust_flag tests/unit/cli/test_cli.py::test_scan_with_fix_rescan_preserves_strict_defaults -q) but the test run was blocked by environment/network limitations while fetching extras (jsonschema) and missing runtime packages (yaml), so full automated tests could not be completed in this environment.

---

Codex Task

[tachyon-beep]

Fixed ourselves in 16a4d005 (PR #28, merged to main) — combined with #25.

The vulnerability is real: a repo-committed .wardline/judged.yaml FALSE_POSITIVE record was applied before the --fail-on gate, so it could suppress a real defect and clear CI. But judged is one of three identical repo-controlled suppression vectors — .wardline/baseline.yaml and wardline.yaml waivers flow through the exact same path (run_scan → apply_suppressions → gate_trips skips non-ACTIVE) and were left fully exploitable by this PR's judged-only scope. So we couldn't merge this as the fix.

#28 closes all three vectors: by default the gate evaluates the unsuppressed population; baseline/waiver/judged still annotate findings but don't clear the gate. The secure CI ratchet is the operator-supplied --new-since <merge-base>; --trust-suppressions (default off) restores the local ratchet for trusted checkouts.

Your contributions were kept, not discarded:

• The verdict: FALSE_POSITIVE hardening in load_judged (reject a hand-edited / missing verdict) is in fix(scan): gate on the unsuppressed population by default (secure --fail-on) — supersedes #24, #25 #28 verbatim — sound, orthogonal, backward-safe.
• Your opt-in trust model is in fix(scan): gate on the unsuppressed population by default (secure --fail-on) — supersedes #24, #25 #28, generalized from a judged-only flag to a single --trust-suppressions covering all three sources, and run_judge passes it through so judge/triage/persist are unchanged — exactly your intent.

Full suite 2406 passed, ruff + mypy clean, repro confirms the gate trips on a suppressed defect by default. Thanks — closing in favour of #28.