`VideoSize.pixelWidthHeightRatio` was never read, so videos stored with non-square pixels (anamorphic content) reported their **coded** size instead of their **display** size. `VideoPlayerValue.size` therefore carried the wrong aspect ratio and such videos rendered stretched.

Example of a real affected file: coded `1080x720` with a `3:8` pixel aspect ratio displays as `405x720`, but `size` was reported as `1080x720` — a 2.67x horizontal stretch.

This scales the reported width by the pixel aspect ratio, which is what media3's own [`PlayerView`](https://github.com/androidx/media/blob/release/libraries/ui/src/main/java/androidx/media3/ui/PlayerView.java) does:

```java
float videoAspectRatio = (height == 0 || width == 0) ? 0 : (width * videoSize.pixelWidthHeightRatio) / height;
```

Both event listeners are updated:

- **Texture path** — ExoPlayer reports a `pixelWidthHeightRatio` that already accounts for any applied rotation (`MediaCodecVideoRenderer` inverts it for 90°/270°), so the ratio is applied to the reported width regardless of the rotation correction.
- **Platform view path** — `Format.pixelWidthHeightRatio` describes the unrotated frame, so the ratio is applied *before* the existing width/height swap.

The scaling is skipped unless the ratio is greater than 0 and not 1, so playback of ordinary square-pixel video is byte-for-byte unchanged.

Verified on a physical anamorphic sample (`1080x720`, SAR `3:8`) on Android 15: previously stretched, now rendered at the correct 9:16 display aspect. iOS is unaffected — `video_player_avfoundation` already reports `presentationSize`, which is pixel-aspect corrected, which is why this bug is Android-only.

*(No before/after screenshots: the sample videos available to me are private medical content and cannot be published.)*

Fixes flutter/flutter#132934
Fixes flutter/flutter#94234

## Pre-Review Checklist

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

Creates a Swift Package Manager target so later PRs can add Swift sources without mixing them into the Obj-C target. CocoaPods still builds both as one pod.

This is packaging-only: Obj-C sources move to `google_sign_in_ios_objc`, and a placeholder Swift target re-exports that module. Plugin behavior is unchanged.

Matches the Obj-C / Swift SPM split already used by `video_player_avfoundation` and `in_app_purchase_storekit`:
- `Package.swift`: `google_sign_in_ios` depends on `google_sign_in_ios_objc`; only the Swift product is exported
- CocoaPods: combined `source_files` glob plus Swift stdlib xcconfig
- Header search path stays `include/google_sign_in_ios` so existing `#import <google_sign_in_ios/...>` keeps working
- Tests: `#if canImport(google_sign_in_ios_objc)` for the Obj-C module

Bumps `google_sign_in_ios` to **6.3.2**.

PR 1/4 of the Obj-C → Swift migration. Follows #12484 (coverage backfill). Part of flutter/flutter#119103

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

Adds build-time detection of routes that resolve to the same URL pattern. `go_router` matches the first route that fits, so a duplicated path silently makes the later route's page unreachable, and `LaterRoute().go(context)` navigates you to `EarlierRoute`'s page instead. Today nothing surfaces that until you run into the issue at runtime.

Reported as a warning by default, and  new `duplicate_route_paths` builder option accepts `warning` (the default), `error`, and `ignore`, so teams whose duplicates are mistakes can fail the build instead.

**Before**, `go_router_builder`'s own example app built clean despite two duplicate registrations:

```
$ dart run build_runner build
[INFO] Succeeded after 14s with 36 outputs
```

**After**:

```
$ dart run build_runner build
W go_router_builder on lib/all_types.dart:
  Duplicate route path detected: DoubleRoute is declared more than once at "double-route/:requiredDoubleField".
```

That duplicate was real. `DoubleRoute` had been registered twice since #2395 (2022) and `DoubleExtensionRoute` since #9458 (2025). Both were unreachable, and this PR removes them. The only change to the generated output is the dead route entries.

What competes for a URL namespace:

- Sibling routes, with path parameters normalized, so `product/:id` and `product/:productId` are one pattern.
- Routes inside shell routes and `StatefulShellRoute` branches, since those own no path of their own and their children compete with the routes around them.
- Relative routes, which own their path like any other route, so `/home/details/edit` and `/home/edit` stay distinct.
- Routes from separate annotations, since the generated `$appRoutes` collects them into one list. Scope is the library, `part` files included.

**Testing:** five new golden inputs in `test_inputs/` cover sibling duplicates, parameter-name-only differences, `StatefulShellRoute` branches, relative routes, cross-annotation duplicates, and the sound same-class grouping case. The golden harness gained two optional companion files per input, documented in the README: `<name>.dart.options` supplies JSON builder options so each severity is exercised through the real option-parsing path, and `<name>.dart.warnings` asserts logged warnings, with an empty file asserting silence.

Fixes flutter/flutter#190741

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

Work towards flutter/flutter#191088

**Ports over #12221 which landed on the `m3e_migration` feature branch.**

### Original PR description

Related to https://github.com/orgs/flutter/projects/250

This PR is just to add the StyleVariant enum so we can start migrating individual components.

## Pre-Review Checklist

**Text exemption:** Adds an enum, no change behavior.

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

Part of flutter/flutter#85160

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

…the local findByTooltip (#12492)

The [find.byTooltip](https://github.com/flutter/flutter/blob/9a353b5ad5e00932819a1ff959f0dc1a65af8f73/packages/flutter_test/lib/src/finders.dart#L396-L415) finder in flutter/flutter's flutter_test package is unreliable for material_ui due to using flutter/flutter's Tooltip class. This PR migrates all usages to the existing [findByTooltip](https://github.com/flutter/packages/blob/a3e763e60321146e9f79571ca917c824b25e62ce/packages/material_ui/test/finders.dart#L24-L43) in material_ui, which does not have this problem.

See flutter/flutter#191063 (comment)

Fixes flutter/flutter#191063

## Description

Fixes an issue where `image_picker` returns a null file after selecting an image from the gallery on Android 16+, caused by incorrect handling of content URIs in the Android implementation.

## Changes

- Updated `ImagePickerUtils.java` to handle Android 16+ behavior correctly
- Fixed file picking logic

## Tests

- Added unit tests for `effectiveUsePhotoPicker` to verify behavior on Android 16 (API 36)
- Ensured correct behavior across API levels

## Issue

Fixes flutter/flutter#182071
Fixes flutter/flutter#184826

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.