[video_player] Add forwardBufferDuration to cap network read-ahead

[mhmdfathy96]

Description

Adds an optional VideoPlayerOptions.forwardBufferDuration so apps can cap how
far ahead of the playhead the player buffers from the network.

Today buffering is fully automatic and aggressive — ExoPlayer's DefaultLoadControl
buffers ~50s, and AVPlayer can prefetch most of a short file on iOS. That wastes
bandwidth whenever a user abandons a video or seeks away. This has been requested
for years without an implementation:

• [video_player] add buffering controls flutter#40931 (2019)
• [video_player] specify buffer sizes flutter#141511
• [video_player]Need to clarify the design philosophy of buffering control in video_player flutter#163918

VideoPlayerController.networkUrl(
  uri,
  videoPlayerOptions: VideoPlayerOptions(
    forwardBufferDuration: const Duration(seconds: 10), // null = unchanged default
  ),
);

The option is threaded through VideoCreationOptions and the pigeon
CreationOptions to the engines:

• Android → ExoPlayer DefaultLoadControl (VideoPlayer.cappedLoadControl,
  with playback-start thresholds clamped to the cap).
• iOS/macOS → AVPlayerItem.preferredForwardBufferDuration (exposed via the
  FVPAVPlayerItem test abstraction).

null preserves current behavior on every platform.

Tests

• Dart: umbrella forwards the option into VideoCreationOptions; android &
  avfoundation pass forwardBufferDurationMs and default to null.
• Android native (Robolectric): cappedLoadControl null/non-null + small-cap
  threshold clamping.
• iOS native (swift-testing): the value is applied to the player item and left
  untouched when null.

All pass locally.

Pre-Review Checklist

• I signed the CLA.
• Unit tests (Dart + Android + iOS) added and passing locally.
• Added/updated CHANGELOG and version bumps for all four packages.
• Listed issues fixed above.
• Generated Dart regenerated with dart run pigeon (android 26.1.5,
  avfoundation 26.3.4 — each matching its committed header) + dart format
  at page width 100. Kotlin/Swift generated files have only the single added
  field in the existing ktfmt/swift-format style.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request adds support for a new forwardBufferDuration option to VideoPlayerOptions and VideoCreationOptions across the video_player packages, allowing users to cap network buffering. The implementation spans the platform interface, Android (ExoPlayer), and iOS/macOS (AVFoundation) implementations, along with corresponding tests. Feedback suggests adding non-negative assertions to the Dart constructors, clamping the duration on Android to prevent integer overflow, and clamping it on iOS/macOS to prevent potential crashes from negative values.

[mhmdfathy96]

Thanks for the review! Addressed in bdc6655:

• iOS negative clamp (high): preferredForwardBufferDuration is now max(0.0, …) to avoid the exception on negative values.
• Android overflow: cappedLoadControl clamps to Integer.MAX_VALUE before the int cast.
• VideoPlayerOptions assert: added the non-negative assertion on the user-facing constructor.
• VideoCreationOptions assert: not added — that constructor is const, and Duration.isNegative isn't a const expression. It's only built internally from an already-validated VideoPlayerOptions, so the user-facing assert above covers it.