feat(platform_interface): add PlatformFile.size

[vicajilau]

Fixes #2187.

The request

PlatformFile.size was removed in the v12 federated rewrite without a synchronous replacement, only Future<int> length() remains. That forces an await for a value most callers already have on hand.

The fix

Every platform's PlatformFile already carries the size the native picker reports, stored in a private _bytesLength field. length() already returns it immediately when it's known and only falls back to actually reading the file (xFile.length()) when it isn't, so the async signature exists for that fallback path, not because getting the size is inherently async.

Added int? get size to PlatformFile, returning that already known value synchronously, null when it isn't known. Matches the shape extension and path already use on this class.

Per platform, what size actually returns:

Platform	Source	Known upfront?
Android	native pick result (FileInfo.size)	Yes
iOS / macOS	native pick result	Yes
Web	browser File.size, or loaded bytes	Yes
Windows	picker only returns a path	No, null
Linux	XDG portal only returns a path	No, null

Windows and Linux callers fall back to await length(), which still works exactly as before.

What changed

• file_picker_platform_interface 3.2.0 → 3.3.0: added the abstract member.
• file_picker_darwin, android_file_picker, file_picker_web bumped (minor): implemented size backed by data they already have.
• file_picker_linux, windows_file_picker bumped (minor): implemented size, returns null since neither picker reports it.
• Each implementation's file_picker_platform_interface lower bound raised to ^3.3.0, the version that introduces the abstract member they now implement. Learned this the hard way with You forgot to bump platform implementations version! #2186, an implementation built against an older interface won't have this override and will fail to compile if pub resolves it alongside a newer interface.
• file_picker (the facade) is untouched, PlatformFile is used through the platform interface as-is, no facade code references size directly.

Test plan

• flutter analyze clean across the whole workspace
• dart format --output=none --set-exit-if-changed clean
• flutter test across the whole workspace, 57 tests pass, including new coverage for size on every platform (web's is @TestOn('browser') like the rest of that file, doesn't run under the default flutter test)

[navaronbracke]

LGTM, although I'm beginning to think we should maybe rethink the facade version checks.

Usually what happens is the platform interface package gets published first, on it's own, then a subsequent release of the child packages can depend on the new platform interface.

Is that a solution to the issue?

[vicajilau]

Thanks! And yes, it does solve the CI part, for a reason worth spelling out: with a staged release the facade never references a version that is not on pub.dev yet. That is the only thing the downgrade smoke test was choking on, so the "skip when unpublished" branch I added to it stops being necessary.

There is a catch though, and it is mine, not yours. It clashes with the guard I put in this PR. tool/test/facade_constraints_test.dart asserts that the facade requires at least the versions the workspace is about to publish, which is lockstep by construction. I simulated your stage one, interface bumped alone with the facade untouched, and it fails on all six:

file_picker_platform_interface: facade allows >=3.2.0 but this repo publishes 3.3.0
android_file_picker: facade allows >=1.0.3 but this repo publishes 1.1.0
file_picker_darwin: facade allows >=1.0.4 but this repo publishes 1.1.0
file_picker_linux: facade allows >=1.0.2 but this repo publishes 1.1.0
windows_file_picker: facade allows >=1.1.0 but this repo publishes 1.2.0
file_picker_web: facade allows >=3.0.3 but this repo publishes 3.1.0

So one of the two has to go. I would keep yours and change what the guard compares against: not "the versions the workspace is about to publish" but "the first published version of each implementation that was built against the interface the facade requires". That works at every stage of a staged release, and it still catches #2186, where the facade asked for interface ^3.2.0 alongside implementations built against ^3.0.0.

One thing staged releases do not remove, just so it is on the record: between publishing the interface and publishing the facade, the new interface is live while the old facade still allows implementations that predate it, so the broken pair is resolvable in that window. It exists in the all-at-once flow too, only shorter. The only thing that actually closes it is not adding abstract members in a minor, giving lengthSync() a default of null instead. That buys safety at the cost of losing the compile error that tells us an implementation forgot to implement it, which for first party implementations is worth a lot.

Doing the guard swap here rather than in a follow-up, so the change and the check that backs it land together.

[navaronbracke]

A follow up is fine, thanks!