This fixes extension installation when Zed's cache directory and data
directory are on different filesystems or mount points. On my Linux
system, `~/.cache` is a separate btrfs subvolume so it can be excluded
from system snapshots, while `~/.local/share` is on the main home
subvolume. Installing extensions failed because extension archives were
unpacked under `paths::temp_dir()` and then renamed into the installed
extensions directory.

The error showed up as:
```text
2026-05-11T17:08:57+02:00 INFO  [extension_host] installing extension dockerfile latest version
2026-05-11T17:08:58+02:00 ERROR [crates/extension_host/src/extension_host.rs:842] Invalid cross-device link (os error 18)
```

Linux rename(2) returns EXDEV (os error 18) across filesystem
boundaries. This is the same class of issue addressed for settings
writes in #8437 and later generalized in
2b3e453d2f3abaaa47c9def4ce5fc63fc017af03. The regression was introduced
by #54355, which made extension updates safer by unpacking into a
temporary directory before renaming into place.

This change creates the temporary unpack directory inside the installed
extensions directory instead. That keeps the final rename on the same
filesystem as the destination while preserving the existing
direct-unpack fallback if creating the temporary directory fails. A
possible alternative would be to create a dedicated temporary install
directory under `extensions/`, alongside `extensions/installed/`. I
chose, however, to keep the temporary directory directly beside the
final destination because that matches the destination-local temp-file
approach used in the earlier fixes referenced above.

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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

No separate issue. The change is small and includes the reproduction
context here. I did not add a regression test because the failure
depends on cache and data directories being on different
filesystems/subvolumes; this was verified manually by reproducing EXDEV
when installing extensions with `~/.cache` on a separate btrfs
subvolume, then confirming the patch fixes extension installation.

Release Notes:

- Fixed installing extensions when Zed's cache and data directories are
on different filesystems.