fix(android): fast step-down + opt-in HD repair for a main with no fmtp (#590)

[badbread]

Fixes #590.

Two independent fixes for a camera whose main stream advertises an RTSP SDP
with no a=fmtp (parameter sets in-band only), which Media3's RTSP client rejects
with IllegalArgumentException: missing attribute fmtp. Captured on device via the
CrumbLiveFallback logging (#561) on a Uniview H.265 LPR main.

1. Fast step-down (client, ships on)

The failure arrives wrapped in an IO error code (2000), so the reactive fallback
ladder retried it across the whole back-off curve (~30 s) before dropping to the
H.264 sub. It is deterministic (identical SDP every attempt), so missing attribute fmtp is added to LiveStreamFallback's deterministic step-down signatures next to
processAggregationPacket. The broken main now steps down to SD on the first
failure.

Narrow by design: matched on the exception-chain message, not by widening any error
code to step down — that would reintroduce the #560 eager-SD regression. A unit
test pins that an fmtp-signature error steps down immediately while a generic 2000
IO error still needs the multi-failure threshold.

2. Opt-in HD repair _mainv (server, default OFF)

A per-camera, detection-driven repaired main <name>_mainv, advertised as
rtsp_mainv_url and tried by Android right after the raw main
(main → mainv → subv → sub → mobile; wall no-sub main → mainv → mobile). It is a
full-resolution H.265→H.264 transcode, gated behind
MAIN_REPAIR_TRANSCODE_ENABLED (default false) because it costs recorder CPU
(libx264) while a fullscreen viewer is attached — go2rtc spawns it lazily, so idle
cost is zero. Detection reuses sdp_video_lacks_fmtp on the MAIN producer (always
warm, the recorder consumes the main through go2rtc), sticky-unknown exactly like
_subv.

Why a transcode and not the cheaper _subv-style copy

Verified empirically against the real LPR stream (ffprobe + tshark RTP capture on
the recorder's embedded go2rtc):

stream	fmtp in SDP?	RTP packetization	Media3
raw main (native restream)	no	FU only, AP-free	fails at DESCRIBE (no fmtp)
ffmpeg:<name>#video=copy	yes	FU + HEVC AP (VPS/SPS/PPS/SEI bundled) at each keyframe	fails on processAggregationPacket
ffmpeg:<name>#video=h264 (this PR)	yes (H.264)	H.264 FU-A/STAP-A	plays

So a copy-remux only trades the fmtp rejection for an Aggregation-Packet crash
(androidx/media#1008). Only a re-encode plays on Android. Full analysis in the
docs/DECISIONS.md 2026-08-08 _mainv entry.

Behavior

• Repair off (default): nothing changes except the instant step-down — an
  fmtp-less main is SD (H.264 sub) on Android, same as before but immediate.
• Repair on: that camera's Android fullscreen becomes HD at recorder CPU cost.
• Cheapest fix for operators who can reach the camera: set its main to H.264 in the
  camera UI (no server transcode). Documented in camera-compatibility.json and the
  env reference.

Tests / verification (gate green on dev2)

• Rust: cargo fmt --all --check, clippy --all-targets -D warnings, cargo test --workspace against a throwaway Postgres (DB-backed tests confirmed to run). New:
  mainv_name_and_src_shapes, mainv_src_is_a_transcode_not_a_copy,
  mainv_src_is_never_an_rtsp_alias_collision, rtsp_mainv_url_*.
• Android: ./gradlew testDebugUnitTest assembleDebug. New:
  the missing-fmtp failure steps down at once…, fullscreen chain puts the repaired main right after the raw main, metered fullscreen keeps the repaired main a last resort…, a no-sub camera puts the repaired main before the transcode…, the repaired main rung is absent when the server does not publish one.
• docker compose config validated on real Docker.

What still needs the maintainer's phone: end-to-end HD playback of the
transcoded _mainv on the LPR (enable MAIN_REPAIR_TRANSCODE_ENABLED, redeploy,
open the LPR fullscreen on Android). The client fast-step-down and all stream-level
facts (SDP fmtp, FU-vs-AP packetization) are verified on the server; only the
on-device render of the transcoded main is unverified.

Do not merge — for maintainer review.