🐛 Handle Compose picker failures without crashing

[vinceglb]

Summary

• catch FileKitPickerException inside non-Android Compose file-picker launchers instead of letting it escape the composition coroutine
• preserve existing launcher signatures while adding onError overloads for explicit failure handling
• add common regression coverage for failure and success paths
• update the gallery sample to surface picker failures and restore its UI state

Root cause

FileKit 0.14.2 correctly converted iOS PhotosUI file-representation failures into FileKitPickerException. The callback-style Compose launcher then invoked the throwing suspend API from an unguarded coroutine, so a recoverable provider failure became an unhandled application crash.

The suspend FileKit.openFilePicker API remains unchanged and continues to throw FileKitPickerException as documented.

Affected platforms

The behavioral fix applies to non-Android Compose launchers, including iOS, macOS, and JVM. Android keeps the mirrored API overload; its Activity Result path already delivers picker states without this coroutine failure mode.

Verification

• regression test observed failing before the fix and passing after it
• ./gradlew :filekit-dialogs-compose:check
• sample shared compilation on iOS simulator, JVM, and Android
• exact CI ktlint command with Compose rules 0.6.0
• ./gradlew assemble
• two-pass standards and crash-spec subagent review, with the sample finding resolved and no remaining material findings