google-apis-core 1.0 (Faraday): download_dest receives gzip-compressed bytes instead of decompressed content

Start by reproducing the issue with the provided google-apis-drive_v3 download_dest example, then inspect the google-apis-core 1.0.2 Faraday migration in PR #23524 and the download_dest path. Done means StringIO, Tempfile, and file-path downloads receive decompressed binary content rather than gzip bytes, while export_file remains working.

Environment details

• Ruby version: 3.3.9
• google-apis-core version: 1.0.2
• google-apis-drive_v3 version: 0.79.0
• faraday version: 2.13+
• OS: Linux (Docker, also reproduced on macOS)

Summary

After upgrading from google-apis-core 0.18.0 (httpclient) to 1.0.2 (faraday), binary file downloads via download_dest receive raw gzip-compressed bytes instead of the decompressed file content. The old httpclient backend handled this transparently via transparent_gzip_decompression.

Steps to reproduce

```ruby
require "google/apis/drive_v3"
require "stringio"

client = Google::Apis::DriveV3::DriveService.new
client.authorization = Google::Auth.get_application_default(["https://www.googleapis.com/auth/drive"])

Download a binary file (e.g., .xlsx) from Google Drive

io = client.get_file("SOME_FILE_ID", download_dest: StringIO.new)
io.rewind
bytes = io.string

puts bytes.encoding #=> UTF-8
puts bytes[0..3].unpack1('H*') #=> "1f8b0800" (gzip magic number)

Expected: "504b0304" (ZIP/XLSX magic number)

```

Expected behavior

download_dest should receive the decompressed file content — the actual XLSX/ZIP binary data with magic bytes PK\x03\x04 (504b0304).

This was the behavior with google-apis-core 0.18.0 using httpclient, which had transparent_gzip_decompression enabled by default.

Actual behavior

download_dest receives raw gzip-compressed bytes (magic bytes \x1F\x8B / 1f8b0800). The content is not decompressed before being written to the IO/file.

This breaks any downstream code that expects the actual file content (e.g., parsing XLSX files with rubyzip or roo):

Zip::Error: Zip end of central directory signature not found

Additional context

• Affects all download_dest targets: StringIO, Tempfile (binmode), and file path strings all receive gzip-compressed content.
• Does not affect export_file: Text exports (CSV, etc.) via export_file work correctly.
• The transparent_gzip_decompression option was deprecated in the Faraday migration (PR #23524), but no equivalent decompression was added for download_dest.
• Workaround: Pin google-apis-core to < 1.0 to continue using the httpclient backend.

Versions

Gem	Working	Broken
google-apis-core	0.18.0 (httpclient)	1.0.2 (faraday)
google-apis-drive_v3	0.66.0	0.79.0

Related: PR #23524 (httpclient → faraday migration)