fix(flet-secure-storage): bump flutter_secure_storage 10.0.0 -> 10.3.1 to fix macOS data-protection keychain (-34018) on unsigned/dev apps

[EH-MLS]

What

Bumps the flutter_secure_storage pin in the flet-secure-storage extension from 10.0.0 to 10.3.1:

• sdk/python/packages/flet-secure-storage/src/flutter/flet_secure_storage/pubspec.yaml — the source-of-truth pin (flutter_secure_storage: 10.0.0 → 10.3.1).

I intentionally left the lockfiles out of this PR: client/pubspec.lock and client/ios/Podfile.lock need regenerating via flutter pub get (and pod install) so the transitive flutter_secure_storage_darwin 0.2.0 → ≥ 0.3.2 (currently 0.4.0) bump and its sha256 hashes land correctly — hand-editing them would produce an inconsistent lockfile. Happy to push the regenerated lockfiles, or for a maintainer to regenerate them in CI. Allow edits by maintainers is enabled.

Why

The current 10.0.0 pin resolves flutter_secure_storage_darwin 0.2.0, which has a Dart→Swift key-name mismatch that makes MacOsOptions(usesDataProtectionKeychain: false) inert — the data-protection keychain is always used. On an unsigned/dev macOS app (no provisioning profile, so no keychain-access-groups entitlement) every write then fails with errSecMissingEntitlement (-34018), and the login-keychain escape hatch is unreachable. That makes it effectively impossible to persist app data/secrets while developing locally on macOS.

Fixed upstream in flutter_secure_storage_darwin:

• key-name fix in 0.3.0 (fix: align macOS options keys in darwin plugin juliansteenbakker/flutter_secure_storage#1047)
• follow-up kSecUseDataProtectionKeychain fix in 0.3.2 (fix: only add kSecUseDataProtectionKeychain if param is set to true juliansteenbakker/flutter_secure_storage#1136)

Both ship transitively via flutter_secure_storage 10.3.1 (current latest stable), so bumping the umbrella pin to 10.3.1 restores a working MacOsOptions(usesDataProtectionKeychain: false) and removes the -34018 failure.

Why bump the pin instead of using dependency_overrides

The [tool.flet.flutter.pubspec.dependency_overrides] workaround suggested in #6586 only fixes flet build, because that path compiles the Flutter client from source and re-reads the pubspec. It does not help flet run: the prebuilt flet-desktop / flet-desktop-full client bundles this extension (its framework ships inside the prebuilt app), built against the default 10.0.0 pin, so it still contains the buggy darwin 0.2.0 keys.

Bumping the single source-of-truth pin is the only change that fixes both paths: flet build (compiled from source) and flet run (the prebuilt client, once a new flet-desktop release ships with this pin).

Verification

With flutter_secure_storage 10.3.1 and MacOsOptions(usesDataProtectionKeychain: false), an unsigned (ad-hoc-signed, no provisioning profile) macOS app successfully wrote and read the login keychain with no -34018. With the default 10.0.0 pin the same app fails on every write.

Notes

• Fixes flutter_secure_storage pinned to 10.0.0 — secure storage unusable on unsigned/dev macOS (darwin 0.2.0 bugs fixed upstream) #6586.
• Happy to add a CHANGELOG.md entry and/or retarget to the active release/v{version} branch if you'd prefer — just let me know.
• I can push the regenerated lockfiles, or hand this off for a maintainer to drive the lockfile regeneration in CI.

Summary by Sourcery

Bug Fixes:

• Resolve macOS keychain write failures on unsigned/dev apps by updating flutter_secure_storage to a version that includes the fixed darwin implementation.

[CLAassistant]

All committers have signed the CLA.

[sourcery-ai]

We've reviewed this pull request using the Sourcery rules engine

[EH-MLS]

Retargeted this to flet-0.86 so it can ride the current release cycle (since main hasn't moved). flet-0.86 is only one commit ahead of main, and that commit doesn't touch this extension's pubspec.yaml, so the diff is unchanged (still the single pin line) and it merges cleanly. Happy to move it back to main if you'd prefer — edits-by-maintainers is on either way.