feat(gate): a camera passes only if a frame came out of a decoder

[cbrightly]

The decode probe shipped advisory in #214 because the measurement had never run
against this fleet, and a gate that has never produced a number is not one to
start blocking releases with. It has now run four times. Promoting it.

Why the old signals are not enough

media_stats.packets counts what the bridge forwarded. recorded_bytes
measures a file written by a -c copy pipeline that never looks inside a
packet. Both are satisfied by bytes of the right shape - which is not a
hypothetical, it is the exact defect #205 fixed, where undecryptable packets
counted as delivered media and a black stream reported healthy indefinitely.

Promoted against the record, not on principle

19 recorded attempts across three fleet runs:

every PASS      -> decoded frames, 46 to 262
every NO_MEDIA  -> zero decoded frames
verdicts that would change under the new rule: 0

So this closes a hole rather than moving the bar. If it had changed a verdict I
would be bringing you the disagreement instead of the change.

The case that mattered most in the design

A probe that could not RUN does not fail the camera. If ffmpeg or ffprobe is
missing on the runner, or the recording is absent, every camera would fail at
once and the gate would be reporting on its own environment rather than on the
fleet. That case defers to the old signals - and it is why the probe reports
decode_error separately from decoded_frames = 0 in the first place. Those
two mean opposite things and collapsing them would be the same species of defect
one level up.

Tested explicitly, including that the two are not confused with each other, and
that the decode check only ever ADDS a condition - it never rescues an attempt
that delivered no media.

The verdict-site guard is a control-flow assertion, verified to fail with
_passes is never called when the verdict goes back to reading ok alone.

Harness only. 1089 passed, 5 skipped.