Failing bidi reader dropped before fan-out causing reader to see clean EOF instead of error

Unconfirmed. This is the result of a search with Claude, may be a false positive.

In the Storage bidi read worker, when `range_end == true` is received, the worker removes the reader from `self.ranges` before calling `pending.handle_data()`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/storage/src/storage/bidi/worker.rs#L224-L232

If `pending.handle_data()` fails (e.g. due to a CRC32C mismatch, short read, or offset mismatch), the `?` operator immediately aborts handling and drops `pending` (and its channel sender).

When the worker subsequently calls `close_readers()`, it iterates only over remaining entries in `self.ranges`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/storage/src/storage/bidi/worker.rs#L183-L192

Because the failed reader was already removed from `self.ranges`, its channel is simply dropped without sending an error. The reader's stream receives `None` and treats the read as a clean EOF with truncated or corrupted data.

Start in src/storage/src/storage/bidi/worker.rs at the range_end handling around lines 224-232, then trace close_readers() around lines 183-192. Verify whether a pending.handle_data() failure drops the reader before its error can reach the stream; done means the behavior is confirmed or disproved and, if confirmed, the reader observes the failure rather than a clean EOF.

Written by the indexing model from the issue text.