fix(webrtc): size H.264 to the negotiated level instead of a fixed cap

[gwdp]

Why

The temporary 1280 cap from #161 was a guess at a symptom. The cause is the negotiated level: libwebrtc builds its VideoToolbox session from profile-level-id in the offer, and past that level's frame size (MaxFS, H.264 Table A-1) it encodes zero frames while the session stays connected.

Browsers advertise Level 3.1, which allows 3600 macroblocks. A 1206x2622 screen is 12464.

Level limits were listed as ruled out in #161. That was wrong; the earlier test rested on a "1920 holds" datapoint that did not reproduce.

How

• H264LevelPolicy maps level_idc to MaxFS and finds the largest long edge that fits
• Read the lowest level advertised in the offer, scale the encode to fit it
• An explicit --max-dimension is clamped the same way; asking past the level yields no picture rather than a bigger one
• Remove the temporary 1280 cap and the picker's matching H.264 ceiling. The --max-dimension ceiling from fix(client): cap the max size picker at --max-dimension  #162 stays

Test Plan

• CI
• Live on an EAS worker: 1206x2622 at Level 3.1 encodes 640x1392, 3480 of 3600 macroblocks, 60fps and no loss
• All live testing ran against a build of the stack tip (feat(webrtc): raise the offer's H.264 level to keep native resolution #171), which carries all five PRs, not this branch alone

[linear-code]

ENG-26485