remote: Disable ControlPersist for master ssh connection

`ControlPersist=yes` combined with `ControlMaster=yes` silently forces
`ForkAfterAuthentication=yes` (even when the user has explicitly set it
to `no` - reported upstream in [0]) - and the latter makes the ssh
subprocess disappear, which makes us think that the connection died

(This is only an issue for people who have `ControlPersist=yes` in their
`ssh_config`, and perhaps the answer is "if that option breaks things,
don't use that option?" - but it's an option that makes sense _most_ of
the time, it's just in this edge-case of "creating an ssh connection
with -N and expecting the process to stay in the foreground" where it
_must_ be set to no)

I think the alternative approach is to tell people "if you want to use
persistent connections, have a separate ~/.ssh/config entry for
servername (to ssh into) and servername-no-persist (to zed into)", which
is possible, but ugh. Kind of a messy situation >.<


Tests:

- Before: Connections to my server result in "Failed to connect: ." (The
error message is attempting to show stderr, but stderr is empty)

- After: Connections to my server work reliably


[0] https://bugzilla.mindrot.org/show_bug.cgi?id=3743


Release Notes:

- N/A

This reverts commit a99750fd35ef4f44409f474228285b1842c1b7d3.

@huacnlee found that commit to have a bad impact on perf and triaged it
for us in
https://github.com/zed-industries/zed/pull/18729#issuecomment-2410445980
Closes #ISSUE

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: Bennet <bennet@zed.dev>

This fixes the panic from the settings file not being embedded.


Release Notes:

- N/A

---------

Co-authored-by: Bennet <bennet@zed.dev>

Previously, we were redirecting to a non-existant page.

Release Notes:

- N/A

- Closes #16998

This PR resolves issues with the /file and /diagnostics commands in the
assistant panel, which previously failed to display the contents of a
directory when searching for a folder instead of using the arrow button.

- Changed the format in `project.rs` (located at
`crates/project/src/project.rs`) to use `std::path::MAIN_SEPARATOR` for
cross-platform compatibility, which resolves errors encountered on
Windows that originally used the format `format!("{}/", ...)`.


Release Notes:

- N/A

- `mold` moved to `sold` long time ago.
  And https://github.com/bluewhalesystems/sold/issues/43...
- And add a step for accepting xcodebuild license

Signed-off-by: Xavier Lau <x@acg.box>

Release Notes:

- vim: Added a few "z" keybindings for scrolling

Similar to e2647025ac833856961a1234ed2bd0202f9c4746, this adds a `regex`
option to `vim::Search` command to allow disabling regex search.

Release Notes:

- Added `regex` option to `vim::Search` command to allow disabling regex
search by default in the keymap. Example usage:
  ```yaml
  {
    "context": "VimControl && !menu",
    "bindings": {
      "/": ["vim::Search", { "regex": false }],
    }
  }
  ```

Update incorrect spelling of Raycast in environment.md

Closes https://github.com/zed-industries/zed/issues/19036

Alters https://github.com/zed-industries/zed/pull/18168 and moves its
change behind a settings flag, restoring the previous behavior.

Release Notes:

- Fixed tab closing not respecting history. Use `tabs.activate_on_close
= neighbour` settings to activate near tabs instead.

Forbid things like
https://github.com/zed-industries/zed/pull/19144#issuecomment-2408871788

Release Notes:

- N/A

This will allow us to compile debug builds of the remote-server for a
different architecture than the one we are developing on.

This also adds a CI step for building our remote server with minimal
dependencies.

Release Notes:

- N/A

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [bytes](https://redirect.github.com/tokio-rs/bytes) |
workspace.dependencies | patch | `1.7.1` -> `1.7.2` |

---

### Release Notes

<details>
<summary>tokio-rs/bytes (bytes)</summary>

###
[`v1.7.2`](https://redirect.github.com/tokio-rs/bytes/blob/HEAD/CHANGELOG.md#172-September-17-2024)

[Compare
Source](https://redirect.github.com/tokio-rs/bytes/compare/v1.7.1...v1.7.2)

##### Fixed

- Fix default impl of `Buf::{get_int, get_int_le}`
([#&#8203;732](https://redirect.github.com/tokio-rs/bytes/issues/732))

##### Documented

- Fix double spaces in comments and doc comments
([#&#8203;731](https://redirect.github.com/tokio-rs/bytes/issues/731))

##### Internal changes

- Ensure BytesMut::advance reduces capacity
([#&#8203;728](https://redirect.github.com/tokio-rs/bytes/issues/728))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzguMTE1LjEiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Closes #19131
Closes #19039

fixes the broken auto-updater.

I had the bright idea of using streams as the most common unit of data
transfer. Unfortunately, streams are not re-usable. So HTTP redirects
that have a stream body (like our remote server and auto update
downloads), don't redirect, as they can't reuse the stream. This PR
fixes the problem and simplifies the AsyncBody implementation now that
we're not using Isahc.

Release Notes:

- N/A

Release Notes:

- N/A

This PR also includes a downgrade of our async_tungstenite version to
0.24

Release Notes:

- N/A

Release Notes:

- N/A

This PR adjusts the billing logic to not write any records to
`billing_events` if:

- The user is staff, as we don't want to bill staff members
- Billing is disabled (we currently enable billing based on the presence
of the Stripe API key)

Release Notes:

- N/A

Release Notes:

- N/A

- Closes: https://github.com/zed-industries/zed/issues/18827

Release Notes:

- N/A

Release Notes:

- N/A

Co-authored-by: Marshall <marshall@zed.dev>

This PR makes the `StripeBilling` object long-lived so that we can make
better use of the cached data on it.

We now hold it on the `AppState` and spawn a background task to
initialize the cache on startup.

Release Notes:

- N/A

Co-authored-by: Richard <richard@zed.dev>

When setting a remote ssh project path starting with ~, Zed would fail
to cd into such project's directory when opening a new terminal.

Release Notes:

- N/A

---------

Co-authored-by: Thorsten Ball <mrnugget@gmail.com>

This PR sorts the order of the LLM database ID type declarations.

Release Notes:

- N/A

This PR adds usage-based billing for LLM interactions in the Assistant.

Release Notes:

- N/A

---------

Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Richard <richard@zed.dev>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>

collab: Remove dependency on X11

I'm not sure if this is the best solution (perhaps pulling
`LanguageName` into a separate `language_types` crate would be
better...?) - but it massively reduces build time / dependencies / size
and means that the collab server no longer requires X11 libraries to be
installed.

tl;dr: `telemetry_events` requires the `language` crate, and the
language crate requires a whole ton of extra stuff. Since
telemetry_events only uses `language` for a single type definition
(`LanguageName`, aka `String`), we can cut all of these out by using the
base `String` type (This doesn't seem too terrible, given that all other
telemetry fields are using basic datatypes like String as opposed to
more strongly-typed variants).


FYI the dependency tree for "why does collab need X11 libraries??" looks
like this:

```
collab
 \- telemetry_events
     \- language
         |- gpui
         |- fuzzy
         |   \- gpui
         |- git
         |   \- gpui
         |- lsp
         |   |- gpui
         |   \- release_channel
         |       \- gpui
         |- settings
         |   |- fs
         |   |   \- gpui
         |   \- gpui
         |- task
         |   \- gpui
         \- theme
             \- gpui
```

Release Notes:

- N/A

This PR adds support to the assistant for display billing-related
errors.

Pulling this out of #19081 to make it easier to cherry-pick.

Release Notes:

- N/A

Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Richard <richard@zed.dev>

terminal: Improve default locale handling

* Use `LANG` instead of `LC_ALL` (`LC_ALL` is the highest priority which
will override any other end-user settings; when that isn't set things
fall back to separate `LC_*` variables; and when those aren't set things
fall back to `LANG`). [0]
* Only set `LANG` for our child if necessary (if it already exists in
the parent, then the child will inherit that, no need for us to do
anything)

[0]
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02

Tested cases:

- `unset LANG ; cargo run`: locale inside zed's terminal is set to
`en_US.UTF-8`
- `export LANG=en_GB.UTF-8 ; cargo run`: locale inside zed's terminal is
set to `en_GB.UTF-8`

Release Notes:

- Use the system locale in the terminal instead of forcing `en_US.UTF-8`

Release Notes:

- N/A

---------

Co-authored-by: Bennet <bennet@zed.dev>

This PR transfers the Gleam extension over to the @gleam-lang
organization:

https://github.com/gleam-lang/zed-gleam

Release Notes:

- N/A

Closes https://github.com/zed-industries/zed/issues/18939

This fixes incorrect width estimates and horizontal scrollbar glitches

Release Notes:

- Fixes horizontal scrollbar not scrolling enough for certain paths
([#18939](https://github.com/zed-industries/zed/issues/18939))

Co-authored-by: Piotr Osiewicz <piotr@zed.dev>

Clicking on

<img width="361" alt="image"
src="https://github.com/user-attachments/assets/b55e2575-b438-4c26-922f-313dc1f41fea">

now opens a read only buffer

<img width="547" alt="image"
src="https://github.com/user-attachments/assets/af82e104-1603-4fe4-9351-635a02cfb4f9">

Previously the buffer would show up as a normal untitled buffer and
would open a prompt when closing the tab.

Co-Authored-by: Thorsten <thorsten@zed.dev>

Release Notes:

- N/A

Co-authored-by: Thorsten <thorsten@zed.dev>

Closes #19050

Release Notes:

- Fixed `worktree.read_text_file` plugin API working incorrectly
([#19050](https://github.com/zed-industries/zed/issues/19050))

Closes https://github.com/zed-industries/zed/issues/18268

Release Notes:

- Fixed Zed not being open filenames with special combination of
brackets ([#18268](https://github.com/zed-industries/zed/issues/18268))

This fixes two things:

- Go-to-def to absolute paths (i.e. opening stdlib files) multiple times
(opening, dropping, and re-opening worktrees)
- Re-opening abs paths from the file picker history that were added
there by go-to-def


Release Notes:

- N/A

---------

Co-authored-by: Bennet <bennet@zed.dev>

Currently terminal.cursor_shape uses `underline` and `cursor_shape` uses
`underscore`.
This standardizes them so they use the same settings value.

I think `underline` is the more common term and it matches the
terminology used by VSCode, Alacritty, iTerm, etc.

Note the protobuf enum `CursorShape::CursorUnderscore` remains
unchanged.

See also:
- https://github.com/zed-industries/zed/pull/18530
- https://github.com/zed-industries/zed/pull/17572

Release Notes:

- Settings: rename one `cursor_shape` from `underscore` to `underline`
(breaking change).

This is a bit of a personal thing, but it's been bugging me for a while
now that the search options are sticky whenever I use `/` in Vim mode.

This change makes it so that the options are reset with each new `/`.

That means you can, for example, use `v` to create a visual selection,
then hit `*` to search for that (which activates a bunch of search
options), but then continue with `/` to get a normal search.

Release Notes:

- Changed `/` in Vim mode to always reset the search options in the
search bar back to regex-only. That means using `*` (in normal or visual
mode) still works with its options, but the next `/` will reset the
search options. That makes it much closer to how `/` behaves in Vim.

Release Notes:

- N/A

- The App Shortcuts in macOS System Settings does not work for Zed since the menu items titles were not set.
- Previously you could set a shortcut for `Zoom`.
- This add support for `Window->Zoom` as well.

Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [wasmtime](https://redirect.github.com/bytecodealliance/wasmtime) |
workspace.dependencies | patch | `24.0.0` -> `24.0.1` |

### GitHub Vulnerability Alerts

####
[CVE-2024-47763](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg)

### Impact

Wasmtime's implementation of WebAssembly tail calls combined with stack
traces can result in a runtime crash in certain WebAssembly modules. The
runtime crash may be undefined behavior if Wasmtime was compiled with
Rust 1.80 or prior. The runtime crash is a deterministic process abort
when Wasmtime is compiled with Rust 1.81 and later.

[WebAssembly tail
calls](https://redirect.github.com/webassembly/tail-call) are a proposal
which relatively recently reached stage 4 in the [standardization
process](https://redirect.github.com/WebAssembly/proposals/). Wasmtime
first enabled support for tail calls by default [in Wasmtime
21.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8540),
although that release contained a bug where it was only on-by-default
for some configurations. In [Wasmtime
22.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8682)
tail calls were enabled by default for all configurations.

The specific crash happens when an exported function in a WebAssembly
module (or component) performs a `return_call` (or
`return_call_indirect` or `return_call_ref`) to an imported host
function which captures a stack trace (for example, the host function
raises a trap). In this situation, the stack-walking code previously
assumed there was always at least one WebAssembly frame on the stack but
with tail calls that is no longer true. With the tail-call proposal it's
possible to have an entry trampoline appear as if it directly called the
exit trampoline. This situation triggers an internal assert in the
stack-walking code which raises a Rust `panic!()`.

When Wasmtime is compiled with Rust versions 1.80 and prior this means
that an `extern "C"` function in Rust is raising a `panic!()`. This is
technically undefined behavior and typically manifests as a process
abort when the unwinder fails to unwind Cranelift-generated frames. When
Wasmtime is compiled with Rust versions 1.81 and later this panic
becomes a deterministic process abort.

Overall the impact of this issue is that this is a denial-of-service
vector where a malicious WebAssembly module or component can cause the
host to crash. There is no other impact at this time other than
availability of a service as the result of the crash is always a crash
and no more.

This issue was discovered by routine fuzzing performed by the Wasmtime
project via Google's OSS-Fuzz infrastructure. We have no evidence that
it has ever been exploited by an attacker in the wild.

### Patches

All versions of Wasmtime which have tail calls enabled by default have
been patched:

* 21.0.x - patched in 21.0.2
* 22.0.x - patched in 22.0.1
* 23.0.x - patched in 23.0.3 
* 24.0.x - patched in 24.0.1
* 25.0.x - patched in 25.0.2

Wasmtime versions from 12.0.x (the first release with experimental tail
call support) to 20.0.x (the last release with tail-calls
off-by-default) have support for tail calls but the support is disabled
by default. These versions are not affected in their default
configurations, but users who explicitly enabled tail call support will
need to either disable tail call support or upgrade to a patched version
of Wasmtime.

### Workarounds

The main workaround for this issue is to disable tail support for tail
calls in Wasmtime, for example with
[`Config::wasm_tail_call(false)`](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call).
Users are otherwise encouraged to upgrade to patched versions.

### References

* [Wasmtime's initial implementation of tail
calls](https://redirect.github.com/bytecodealliance/wasmtime/pull/6774)
* [Enabling of tail calls in
21.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8540)
* [Fully enabling tail calls in
22.0.0](https://redirect.github.com/bytecodealliance/wasmtime/pull/8682)
* [The WebAssembly's `tail-call`
proposal](https://redirect.github.com/webassembly/tail-call)

####
[CVE-2024-47813](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m)

### Impact

Under certain concurrent event orderings, a `wasmtime::Engine`'s
internal type registry was susceptible to double-unregistration bugs due
to a race condition, leading to panics and potentially type registry
corruption. That registry corruption could, following an additional and
particular sequence of concurrent events, lead to violations of
WebAssembly's control-flow integrity (CFI) and type safety. Users that
do not use `wasmtime::Engine` across multiple threads are not affected.
Users that only create new modules across threads over time are
additionally not affected.

Reproducing this bug requires creating and dropping multiple type
instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`)
concurrently on multiple threads, where all types are associated with
the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.**
See the "References" section below for a list of Wasmtime types-related
APIs that are affected.

Wasmtime maintains an internal registry of types within a
`wasmtime::Engine` and an engine is shareable across threads. Types can
be created and referenced through creation of a `wasmtime::Module`,
creation of `wasmtime::FuncType`, or a number of other APIs where the
host creates a function (see "References" below). Each of these cases
interacts with an engine to deduplicate type information and manage type
indices that are used to implement type checks in WebAssembly's
`call_indirect` function, for example. This bug is a race condition in
this management where the internal type registry could be corrupted to
trigger an assert or contain invalid state.

Wasmtime's internal representation of a type has individual types (e.g.
one-per-host-function) maintain a registration count of how many time
it's been used. Types additionally have state within an engine behind a
read-write lock such as lookup/deduplication information. The race here
is a time-of-check versus time-of-use (TOCTOU) bug where one thread
atomically decrements a type entry's registration count, observes zero
registrations, and then acquires a lock in order to unregister that
entry. However, between when this first thread observed the
zero-registration count and when it acquires that lock, another thread
could perform the following sequence of events: re-register another copy
of the type, which deduplicates to that same entry, resurrecting it and
incrementing its registration count; then drop the type and decrement
its registration count; observe that the registration count is now zero;
acquire the type registry lock; and finally unregister the type. Now,
when the original thread finally acquires the lock and unregisters the
entry, it is the second time this entry has been unregistered.

| Thread A                          | Thread B                       |
|-----------------------------------|--------------------------------|
| `acquire(type registry lock)`     |                                |
|                                   | `decref(E) --> 0`              |
|                                   | `block_on(type registry lock)` |
| `register(E') == incref(E) --> 1` |                                |
| `release(type registry lock)`     |                                |
| `decref(E) --> 0`                 |                                |
| `acquire(type registry lock)`     |                                |
| `unregister(E)`                   |                                |
| `release(type registry lock)`     |                                |
|                                   | `acquire(type registry lock)`  |
|                                   | `unregister(E)`          |

This double-unregistration could then lead to a WebAssembly CFI
violation under the following conditions: a new WebAssembly module `X`
was loaded into the engine before the second, buggy unregistration
occurs; `X` defined a function type `F` that was allocated in the same
type registry slot where the original entry was allocated; the second,
buggy unregistration incorrectly unregistered `F`; another new
WebAssembly module `Y` was loaded into the engine; `Y` defined a
function type `G`, different from `F`, but which is also allocated in
the same type registry slot; a `funcref` of type `G` is created, either
by the host or by Wasm; that `funcref` is passed to a WebAssembly
instance of module `X`; that instance performs a `call_indirect` to that
`funcref`; the `call_indirect`'s dynamic type check, which preserves
CFI, could incorrectly pass in this case, because `F` and `G` were
assigned the same type registry slot. This would, ultimately, allow
calling a function with too many, too few, or wrongly-typed arguments,
violating CFI and type safety.

We were not able to reproduce this CFI violation in a vanilla Wasmtime
build, although it remains theoretically possible. However, by modifying
Wasmtime's source code to make losing the races described above more
likely (by disabling certain assertions, inserting panic catches, and
adding retry loops in a few places if we did *not* lose the race) we
were able to incorrectly get a `funcref` to pass a type check that it
should have failed, which would allow the CFI violation.

### Patches

This bug was originally introduced in Wasmtime 19's development of the
WebAssembly GC proposal. This bug affects users who are not using the GC
proposal, however, and affects Wasmtime in its default configuration
even when the GC proposal is disabled. Wasmtime users using 19.0.0 and
after are all affected by this issue. We have released the following
Wasmtime versions, all of which have a fix for this bug:

* 21.0.2
* 22.0.1
* 23.0.3
* 24.0.1
* 25.0.2

### Workarounds

If your application creates and drops Wasmtime types on multiple threads
concurrently, there are no known workarounds. Users are encouraged to
upgrade to a patched release.

### References

The following APIs create or drop types, and therefore are affected by
this race condition if performed on multiple threads concurrently and
are all associated with the same `wasmtime::Engine`:

*
[`wasmtime::FuncType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.FuncType.html#method.new)
* Also reachable from creation of
[`wasmtime::Func`](https://docs.rs/wasmtime/latest/wasmtime/struct.Func.html)
* Also reachable from
[`wasmtime::Linker::func_*`](https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html#method.func_new)
*
[`wasmtime::ArrayType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayType.html#method.new)
*
[`wasmtime::StructType::new`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructType.html#method.new)
*
[`wasmtime::Func::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Func.html#method.ty)
*
[`wasmtime::Global::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Global.html#method.ty)
*
[`wasmtime::Table::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Table.html#method.ty)
*
[`wasmtime::Extern::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Extern.html#method.ty)
*
[`wasmtime::Export::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Export.html#method.ty)
*
[`wasmtime::UnknownImportError::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.UnknownImportError.html#method.ty)
*
[`wasmtime::ImportType::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ImportType.html#method.ty)
*
[`wasmtime::ExportType::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ExportType.html#method.ty)
*
[`wasmtime::Val::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Val.html#method.ty)
*
[`wasmtime::Ref::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.Ref.html#method.ty)
*
[`wasmtime::AnyRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.AnyRef.html#method.ty)
*
[`wasmtime::EqRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.EqRef.html#method.ty)
*
[`wasmtime::ArrayRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayRef.html#method.ty)
*
[`wasmtime::StructRef::ty`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructRef.html#method.ty)
* Dropping a
[`wasmtime::FuncType`](https://docs.rs/wasmtime/latest/wasmtime/struct.FuncType.html)
* Dropping a
[`wasmtime::ArrayType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ArrayType.html)
* Dropping a
[`wasmtime::StructType`](https://docs.rs/wasmtime/latest/wasmtime/struct.StructType.html)
* Dropping a
[`wasmtime::ExternType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ExternType.html)
* Dropping a
[`wasmtime::GlobalType`](https://docs.rs/wasmtime/latest/wasmtime/struct.GlobalType.html)
* Dropping a
[`wasmtime::TableType`](https://docs.rs/wasmtime/latest/wasmtime/struct.TableType.html)
* Dropping a
[`wasmtime::ValType`](https://docs.rs/wasmtime/latest/wasmtime/struct.ValType.html)
* Dropping a
[`wasmtime::RefType`](https://docs.rs/wasmtime/latest/wasmtime/struct.RefType.html)
* Dropping a
[`wasmtime::HeapType`](https://docs.rs/wasmtime/latest/wasmtime/struct.HeapType.html)
* Dropping a
[`wasmtime::UnknownImportError`](https://docs.rs/wasmtime/latest/wasmtime/struct.UnknownImportError.html)
* Dropping a
[`wasmtime::Linker`](https://docs.rs/wasmtime/latest/wasmtime/struct.Linker.html)

The change which introduced this bug was
[#​7969](https://redirect.github.com/bytecodealliance/wasmtime/pull/7969)

---

### Release Notes

<details>
<summary>bytecodealliance/wasmtime (wasmtime)</summary>

###
[`v24.0.1`](https://redirect.github.com/bytecodealliance/wasmtime/releases/tag/v24.0.1)

[Compare
Source](https://redirect.github.com/bytecodealliance/wasmtime/compare/v24.0.0...v24.0.1)

#### 24.0.1

Released 2024-10-09.

##### Fixed

- Fix a runtime crash when combining tail-calls with host imports that
capture a
    stack trace or trap.

[GHSA-q8hx-mm92-4wvg](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg)

- Fix a race condition could lead to WebAssembly control-flow integrity
and type
    safety violations.

[GHSA-7qmx-3fpx-r45m](https://redirect.github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "" in timezone America/New_York,
Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

Release Notes:

- N/A

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMTQuMCIsInVwZGF0ZWRJblZlciI6IjM4LjExNC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

As Zed instantly shows completion items in the completion menu, and the
resolve will cause the details to appear, flickering.
We can safely resolve the `documentation`, `additionalTextEdits` and
`command` fields, the rest should be resolved eagerly for now.

Release Notes:

- Fixed completion menu rendering