fix(security): gate radio-affecting threat action on calibration and authorization

[forkwright]

Addresses the authorization gap on #874 — the part that gates #862's callers. Does not close the issue; detector-output provenance and the spoofed/stale/replayed evidence coverage remain its open work.

The rule this broke is already written down

evaluate_threat compared a caller-supplied score to a caller-supplied threshold and, above it, drove the firewall into Panic and recorded a modem power-cut request. Two FIXME(#874) markers sat on those exact lines.

sema_core::Calibration's own doc states the canon:

Any future automatic response must match on Calibrated before it may act.

The threat bands are provisional score ranges (#555) — High is documented as "labeled 'likely IMSI catcher' only after calibration establishes what the band actually separates". So a threshold crossing on an uncalibrated detector is a statement about arithmetic, not about the world. It now returns Advisory(Uncalibrated) and touches neither the firewall nor the power manager, even at u32::MAX and even with an authorization standing.

A second gate, because calibration is not consent

A detector that is right most of the time still does not get to disconnect someone's phone on its own. That is an operator's decision, and RadioCutAuthorization is where it enters.

There is deliberately no Default and no constructor deriving it from a score — the failure being prevented is a detector authorizing itself. OperatorAccepted exists so the plumbing is written and tested; no production path can build one today because no operator-acceptance mechanism exists yet. When one lands it constructs this value, and nothing else has to change to let the action through.

Why the two refusals are separate variants, and why the order matters

State	Response
uncalibrated	Advisory(Uncalibrated)
calibrated, unauthorized	Advisory(NotAuthorized)
calibrated + authorized, over threshold	ModemCutRequested

They resolve at different times and from different sources — calibration from an evaluation harness, authorization from an operator. Collapsing them would make the eventual arrival of calibration look like nothing had changed.

The calibration check runs first, and that is deliberate: an operator who authorized action on a calibrated detector did not thereby authorize it on an uncalibrated one, so reporting NotAuthorized there would name the wrong missing thing.

Sentinel firewall restriction stays ungated. It follows the operating mode the operator selected rather than a detector score, restricts rather than severs, and is reversible by leaving the mode. A test passes an uncalibrated detector through that path on purpose, to pin that the gates cover radio-affecting action and not every effect.

The kardia badge: the missing fixture was the defect, not the expression

The threat indicator had already been corrected from a CCCI boot-path artefact to detector_online && High|Critical. That correction was right — and nothing guarded it. kardia.rs has no test module at all, and scripts/witness/boot.sh asserts modem_path_available but never threat_high. So reverting to the old derivation would have passed the entire suite and the boot witness.

VERIFICATION.md says a claim without a failing fixture cannot be passed. This extracts screen_threat::threat_indicator and covers the full cross product.

The offline row is the one that matters: a detector that has stopped reporting must not leave the badge asserting whatever it last saw. All four levels are checked against detector_online = false, not just the convenient one.

Verified

Nine-configuration scripts/kernel-clippy.sh clean, cargo fmt --check clean. Full kernel suite on the host target: 2466 tests, 43 failures — exactly the unmodified-main baseline, compared name-by-name against a captured baseline set. Ledger rows updated (security_mode 36 → 39, screen_threat 23 → 24).