Fix Apple H.264 profile-level capability advertisement

[hiroshihorie]

Summary

• Query VideoToolbox on Apple platforms to derive the max advertised H.264 level per profile family.
• Translate VideoToolbox profile-level constants into WebRTC's H264Profile / H264Level model. The fixed list is a constant mapping, not a device capability table; the capability decision still comes from VideoToolbox's supported value list.
• Keep the existing iOS UIDevice capability table as the conservative fallback for older physical iOS builds where VideoToolbox cannot be constrained to the hardware encoder.
• Avoid the historical Level 3.1 fallback on macOS/Catalyst/simulator-style Apple targets when VideoToolbox returns no useful H.264 profile list, since Level 3.1 can make 1080p30 non-simulcast publishing fail.
• If VideoToolbox returns a useful H.264 list but omits a profile family, do not invent support for that profile family. Let the caller fall back to WebRTC's historical constants instead.
• Preserve the existing H.264 profile ordering: ConstrainedHigh remains first for VideoToolbox's low-latency hardware path, and ConstrainedBaseline remains available for interop fallback.
• Declare the direct VideoToolbox.framework dependency from sdk:videocodec_objc, because RTCH264ProfileLevelId.mm now owns VideoToolbox symbol references.

Context

LiveKitWebRTC should advertise Apple H.264 encoder capabilities accurately from the WebRTC SDK itself, without relying on downstream SDP profile-level rewrites.

Physical iOS already had a device capability table, but macOS/Catalyst did not. Those targets could still fall back to WebRTC's Level 3.1 constants, which cap 1920x1080 to roughly 13 fps and can lead to VideoToolbox encode failures for 1080p30 publishing.

This patch moves that decision into the WebRTC SDK's Apple H.264 profile-level code by asking VideoToolbox what the current platform supports, while keeping the older iOS table as a fallback where it is still the safer signal.

The H.264 VideoToolbox encoder only enables kVTVideoEncoderSpecification_EnableLowLatencyRateControl for High-family profiles, because applying it with Baseline/Main disables hardware acceleration. Keeping ConstrainedHigh first preserves that low-latency path when negotiation supports it.

Validation

• git diff --check origin/m144_release...HEAD
• Earlier local compile check before the latest review-only follow-ups: autoninja -C out/codex-mac sdk:videocodec_objc

[hiroshihorie]

Formatting preference for future edits on this PR: clang-format touched Obj-C++ lines/blocks with { IndentWidth: 2, BasedOnStyle: google, ColumnLimit: 120, DerivePointerAlignment: false, PointerAlignment: Right }. GN files should continue to follow GN formatting.