When extracting gzip tar files, the `GzipDecoder` was being pinned
directly over the response body stream. This caused issues because the
decoder needs to read the entire stream into memory before the `Archive`
can be created and used.

Buffer the decompressed bytes into a `Vec` first, then create the
decoder over that in-memory buffer to ensure all data is available when
needed.

Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Closes [Java extension issue
222](https://github.com/zed-extensions/java/issues/222)

Testing:
**Automated:**
- `cargo test -p extension_host
test_extension_store_with_test_extension` — integration test that
exercises the full `download_file` → `GzipTar` → `extract_tar_file` path
through a WASM extension with a `FakeHttpClient` serving a real gzipped
tar archive. Passed.

**Manual:**
- Built and ran Zed with `cargo +nightly run`, deleted and reinstalled
the Java extension. The extension's language server download completed
successfully and all expected files were extracted.

Release Notes:

- Fixed extension `download_file` with `GzipTar` silently dropping
archive entries by buffering the full HTTP response before extraction,
matching the approach already used for extension installation. See
https://github.com/zed-industries/zed/blob/c6bdb697343cd470f96a56a5c5d288524baf4599/crates/extension_host/src/extension_host.rs#L761