fix(doctor): report unsupported video encodings and missing schemas separately from read-failed

[Sagar-024]

fix(doctor): report unsupported video encodings and missing schemas separately from read-failed

Closes #460.

What changed

Doctor's video check previously ran inside one broad try block. That meant two failures that weren't actually corruption problems ended up being reported as read-failed, along with the misleading "corrupt chunk or bad CRC?" assertion.

Unsupported video encodings

_resolve_video_decoder raises when neither supported decoder factory (ROS2 or protobuf) can handle a channel's message_encoding.

That isn't evidence of corrupted bytes or a machine codec problem. It simply means the file uses an encoding that isn't supported by our current decoder set.

This now reports as video-encoding-unsupported, including the topic name and a detail message making it clear that the file bytes themselves are not implicated. The resolver now raises the typed VideoEncodingUnsupported, which remains a ValueError subclass.

Missing schemas

The existing in-loop schema is None check was effectively dead code.

There are two reasons:

• A channel with a dangling schema gets an empty schema name, so it never gets classified as a video channel.
• The reader raises KeyError during iteration before the loop body can reach that check.

The missing-schema case is now handled in a summary pre-pass instead. Any channel that references a schema ID not present in the file reports channel-schema-missing.

schema_id == 0 remains valid and means the channel is schemaless.

Channels with missing schemas are excluded from the read pass using the reader's topics filter, which keeps read-failed reserved for actual read and CRC failures.

Severity

Both findings remain ERROR.

Doctor is certifying episode conformance. If a video topic uses an encoding our decoder set cannot handle, the episode can't be fully certified because downstream readers rely on that same decoder support.

Making this a WARNING would allow Doctor to certify a file whose video was never actually checked.

The distinction is reflected in the finding codes and messages, which now describe what actually happened. The severity represents "cannot certify," consistent with findings such as no-statistics and no-chunk-indexes.

Behavior notes

• Healthy files: No behavioral change. When all channels are valid, the read pass remains unfiltered and follows the exact same path as before.
• Excluded topics: Chunks containing only excluded topics are no longer CRC-validated during the read pass. Previously, iteration would stop at the first exception anyway, so CRC coverage for later chunks in already-broken files was already incomplete. Healthy files still receive the full pass.
• Zero-message channels: Decoder resolution now happens during the summary pre-pass, so unsupported video channels with zero messages are reported instead of remaining silent.

Tests

23 passed in tests/test_doctor.py, including two new real-path tests with no stubs:

• A JSON-encoded video channel reports video-encoding-unsupported and never read-failed.
• A channel with a fabricated schema ID (99) alongside a healthy sibling reports channel-schema-missing and never read-failed, while the sibling's video checks still run.

Mutation checks also confirmed the new coverage: removing either the pre-pass or the encoding catch makes exactly the two new tests fail. Restoring them brings everything back to green.

ruff check, ruff format, and ty are all clean.