fix: improve initial video quality by setting x-google-start-bitrate for all video codecs

[xianshijing-lk]

Summary

• Add x-google-start-bitrate SDP munging for all video codecs (VP8, VP9, AV1, H264, H265)
• Use 90% of target bitrate as start bitrate to prevent initial blurriness
• Default degradationPreference to .maintainResolution for video tracks

Problem

Video starts blurry for 5-15 seconds before improving. This is caused by WebRTC's bandwidth estimator starting at ~300kbps and slowly ramping up to the target bitrate.

Solution

1. x-google-start-bitrate: Tell WebRTC to start at 90% of target bitrate instead of ramping up from ~300kbps. Applied consistently to all video codecs.
2. MaintainResolution: When bandwidth is constrained, prefer dropping frames over reducing resolution. This maintains video clarity at the cost of smoothness.

Changes

• Added TrackBitrateInfo struct and tracking in Transport
• Added setTrackBitrateInfo() method to register bitrate info when publishing video tracks
• Added mungeStartBitrate() SDP munging function
• Updated negotiate sequence to apply start bitrate munging
• Changed default degradationPreference from .auto to .maintainResolution

Test plan

• Verify video quality is sharp from the start when publishing
• Test with VP8, VP9, H264, AV1 codecs
• Verify bandwidth estimator adapts properly if network can't handle the start bitrate

🤖 Generated with Claude Code

[pblazej]

A few suggestions:

• Per-codec, not global max. We compute max(maxBitrateKbps) across all tracks and stamp that single value onto every video payload. The consensus in the thread was "0.9× of that codec's target." It happens to work because one codec is negotiated at a time, but it's not what it says on the tin.
• H264 loses payloads. codecPayloads[codecName] = payload keeps only the last payload per codec name. H264 commonly advertises several profile payloads; only one gets the hint. (Low impact since H264 doesn't benefit anyway, but it shows the matching is loose.)
• Can be static like mungeInactiveToRecvOnlyForMedia — it uses no instance state.
• Needs a test. This is non-trivial string parsing (CRLF detection, fmtp insert-vs-append, payload matching) with no coverage. Please add a unit test that feeds a representative VP9/AV1 offer and asserts the resulting a=fmtp line.

[pblazej]

Changing the degradationPreference default to .maintainResolution is the right call — it's the consensus from the investigation thread and the change that actually fixed the reported VP8 case (the x-google-start-bitrate munging is confirmed to be a no-op for VP8/H264 and only helps SVC codecs). Please add a changeset entry for it, since it's a public default-behavior change for camera publishing. Also needs a lint/format pass — CI is red.