fix: accept Android document-provider export paths

[jpdexter101-lang]

What this fixes

Fixes #763.

On Android, file_picker 11 writes through the selected Storage Access Framework content:// URI, then returns uri.path. That value looks like /document/primary:Download/... but is not a real dart:io filesystem path. When Downloads auto-renames an existing export to (2).zip, the export verifier tries to stat the provider path and reports a valid export as failed.

This change treats Android document-provider paths the same as content:// URIs while retaining strict byte-length verification for real filesystem paths.

Verification

• dart format lib/core/utils/export_write_verifier.dart test/unit_test/export_write_verifier_test.dart
• flutter test test/unit_test/export_write_verifier_test.dart — 7 tests passed
• git diff --check — passed
• flutter analyze was attempted, but the checkout is missing the repository's lib/generated/l10n.dart localization output and reports broad pre-existing generated-code errors; the focused test suite passes.

[simonoppowa]

Not a 2.2.0 blocker, and one note if you do land it

Reviewed in a release-readiness audit before #988.

The defect is real and somewhat broader than the description says — the false failure is not limited to the path shape the title names. It is a good fix.

It is not a release gate, though: it affects export rather than anything 2.2.0 introduces, and users hitting it have been hitting it since before v2.0.2.

If you do want it in: it is small (2 files, no pubspec change, no schema change), but it comes from a fork, so its workflow run needs approving first — merge only on green, since nothing in main's branch protection will stop a red merge.