[firebase_storage] Windows native crash in upload progress callback, sink ownership and thread dispatch

Concurrent `putData` calls can terminate the Windows process with an unhandled access violation in `TaskStateListener::OnProgress` / `flutter::EventSink::Success`. A Dart catch cannot catch this native exit.

Reproduced with firebase_storage 12.4.10, Firebase C++ SDK 12.7.0, and a Windows release build on Windows Server 2019 (17763). The relevant ownership and callback code is also present in current `main` (a57837ef40f73f0187b45125ecc0d81811b71bd9, firebase_storage 13.5.0); I have inspected that source but have not runtime-tested 13.5.0.

After normal Firebase initialization and authentication, run repeated bursts of small uploads to an authorized test path:

```dart
final bytes = Uint8List.fromList(utf8.encode(jsonEncode({
'id': List.generate(300, (i) => i),
'label': List.generate(300, (i) => 'Synthetic customer $i'),
})));
for (var round = 0; round < 3; round++) {
await Future.wait(List.generate(13, (i) => FirebaseStorage.instance
.ref('YOUR_TEST_PATH/${DateTime.now().microsecondsSinceEpoch}_$i.json')
.putData(bytes, SettableMetadata(contentType: 'application/json'))));
}
```

The storage-only reproduction initializes Core/Auth/Storage, with no Hive, Firestore database initialization, or SQL. The unchanged plugin exited with `0xC0000005` about 14 seconds into one run. A separate release-app dump identifies the progress callback stack:

```text
flutter::EventSink::Success
TaskStateListener::OnProgress
firebase::storage::internal::RestOperation::NotifyListenerOfProgress
```

Three relevant findings in the Windows plugin:

- `PutDataStreamHandler`, `PutFileStreamHandler`, and `GetFileStreamHandler` store the sink as a `std::unique_ptr<...>&&` member. `OnListenInternal` assigns into that referenced temporary instead of owning the incoming sink.
- Progress and completion call `EventSink::Success` from SDK worker threads. Flutter's platform message API requires the platform thread.
- Keeping only the sink alive was insufficient in our stress checks: transfers could upload remotely while Dart completions remained pending. Keeping the exact `StorageReference` that starts each operation alive through completion, and moving completion processing onto the platform thread, resolved the tested stalls. SDK 12.7 source shows a potential FutureManager/API mutex inversion when a reference is orphaned during a pending Metadata result; I am not claiming the dump alone proves that entire lock cycle.

A local plugin candidate owns the sinks, posts events through a message-only Windows window, retains operation references and buffers until completion, and drops callbacks after plugin shutdown. It has passed 140 small uploads with byte-for-byte SDK readback (including ten bursts of 13), metadata updates, putString, putFile/writeToFile, overwrite, download URL, a 13 MB result, accepted pause/resume, eight accepted cancellations, missing-object and signed-out errors, and uploads after signing back in. The unchanged native plugin still crashes with the same Dart harness. Requested close during 13 active uploads exits without leaving a process. A separate super_native_extensions/msctf error during requested process shutdown also occurs without any Storage upload in the unchanged plugin, and in our previous full-app build; that is outside this report.

Candidate patch: https://github.com/BlazeSQL/flutterfire/commit/f9ea66025cbdd8b2b32fa762282194b4ba454d40 (based on our existing Firestore fork; this commit changes only Windows Storage).

Could you confirm the intended sink/reference lifetime and platform-thread dispatch approach? I can supply a minimal patch or further diagnostics. No customer data is needed to reproduce this.

Start with the Windows PutDataStreamHandler, PutFileStreamHandler, and GetFileStreamHandler ownership and callback paths, then run the supplied concurrent putData harness on Windows. Compare the unchanged plugin with commit f9ea66025cbdd8b2b32fa762282194b4ba454d40 and its listed stress checks. Done means repeated uploads complete without a native crash or pending Dart completions, with byte-for-byte SDK readback.

Written by the indexing model from the issue text.