fix(storage): handle early stream destruction in createReadStream

[thiyaguk09]

Description

Prevents an unhandled ERR_STREAM_UNABLE_TO_PIPE exception in File#createReadStream when the downstream stream is destroyed or closed before the GCS HTTP response arrives.

Impact

Eliminates process crashes caused by synchronous ERR_STREAM_UNABLE_TO_PIPE errors thrown inside the asynchronous response callback when a downstream consumer disconnects early, while ensuring the underlying HTTP response stream is properly cleaned up to prevent memory or socket leaks.

Changes

• Check throughStream.destroyed in File#createReadStream's response handler before invoking pipeline(), destroying or draining rawResponseStream and returning early if the destination stream is already destroyed.
• Wrap the pipeline() call in a try...catch block to catch ERR_STREAM_UNABLE_TO_PIPE, suppress the pipeline completion error handler, safely destroy or drain rawResponseStream, and swallow the error while rethrowing any other unexpected errors.

Testing

• Added a unit test in handwritten/storage/test/file.ts verifying that rawResponseStream is destroyed and pipeline() is not called when throughStream is already destroyed before the response callback runs.
• Added a unit test in handwritten/storage/test/file.ts verifying that an ERR_STREAM_UNABLE_TO_PIPE error thrown by pipeline() is caught and swallowed and that rawResponseStream is destroyed.

Fixes #7603

[gemini-code-assist]

Code Review

This pull request introduces robust error handling and resource cleanup when piping streams in File.ts, specifically addressing scenarios where the target stream is already destroyed or when an ERR_STREAM_UNABLE_TO_PIPE error is thrown. Corresponding unit tests have been added to verify these behaviors. The feedback suggests correcting a TypeScript type cast from RequestError to any (or a generic error type with a code property) to avoid potential compilation issues and semantic inaccuracy, as the error is a standard Node.js stream error.