Manual backport of https://github.com/zed-industries/zed/pull/48959 to
stable.

Co-Authored-By: Cameron <cameron@zed.dev>

Cherry-pick of #48822 to preview

----
Closes #48712

- [ ] Tests or screenshots needed?
- [ ] Code Reviewed
- [ ] Manual QA

Release Notes:

- Fixed a panic when parsing predictions made by zeta1

Co-authored-by: Ben Kunkle <ben@zed.dev>

Cherry-pick of #48555 to preview

----
Reverts zed-industries/zed#48528

Release Notes:

- N/A

Co-authored-by: Mikayla Maki <mikayla@zed.dev>

Cherry-pick of #48513 to preview

----
Closes #46506

Release Notes:

- Fixed an issue where the codestral URL used for credentials would be
different than the one used for requests causing authentication errors

Co-authored-by: Ben Kunkle <ben@zed.dev>

Cherry-pick of #48528 to preview

----
Release Notes:

- N/A

Co-authored-by: Mikayla Maki <mikayla@zed.dev>

Cherry-pick of #48508 to preview

----
<img width="588" height="485" alt="Screenshot 2026-02-05 at 1 29 10 PM"

src="https://github.com/user-attachments/assets/f3d36c8b-b371-4226-af60-bdc2c6b34009"
/>
<img width="586" height="468" alt="Screenshot 2026-02-05 at 1 30 15 PM"

src="https://github.com/user-attachments/assets/878e91ad-948c-4b35-a37b-f5a8db7e0b3f"
/>


This adds Claude Opus 4.6 as a new Anthropic model, along with 1M
context window variants for both Opus 4.6 and Sonnet 4.5.

## Opus 4.6

Adds `ClaudeOpus4_6` and `ClaudeOpus4_6Thinking` with the same
properties as other Claude 4+ models (200k context, 8192 max output
tokens, fine-grained tool streaming beta header).

## 1M context variants

Adds 1M context window variants for Sonnet 4.5 and Opus 4.6. These are
identical to their base models except:
- Context window is 1,000,000 tokens instead of 200,000
- They send the `context-1m-2025-08-07` beta header

Release Notes:

- Added Claude Opus 4.6
- Now Claude Opus 4.6 and Sonnet 4.5 BYOK models support variations that
have context windows of 1 million tokens (and have different pricing)

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

Cherry-pick of #48410 to preview

----
Release Notes:

- N/A

Co-authored-by: Kenan Hasanaliyev <claserken@gmail.com>

Cherry-pick of #48229 to preview

----
Closes #ISSUE

Release Notes:

- N/A *or* Added/Fixed/Improved ...

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

Co-authored-by: Katie Geer <katie@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>

Cherry-pick of #48225 to preview

----
Closes #ISSUE

Release Notes:

- N/A *or* Added/Fixed/Improved ...

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Zed Zippy
<234243425+zed-zippy[bot]@users.noreply.github.com>

Co-authored-by: Katie Geer <katie@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>

Cherry-pick of #48306 to preview

----
### Summary
Adds accept/reject tracking for Mercury edit predictions.

### Changes
Sends events to https://api-feedback.inceptionlabs.ai/feedback when:

Accept — user presses Tab
Reject — user presses Escape
Ignore — prediction dismissed implicitly (typing, cursor move, etc.)

Added `discard_explicit` method to the delegate trait to distinguish
explicit vs implicit dismissal. Updated `reject_prediction` and
`reject_current_prediction` methods with an `explicit` bool parameter to
thread this through to the Mercury feedback logic. Other providers are
unaffected—they use the default implementation.

Feedback is fire-and-forget in a background thread, only sent for
predictions that were shown.

### Data Collected
- Request ID (returned from Inception API)
- User action (either accept/reject/ignore)
- Client Zed version (to track updates made to Zed client which could
potentially affect nextedit implementation)


Release Notes:

- N/A

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

Co-authored-by: Kenan Hasanaliyev <claserken@gmail.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>

Closes #ISSUE

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Zeta 1 should not be configurable, not by this setting.

Release Notes:

- N/A

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

Otherwise block_with_timeout is effectively useless on windows as we
would block a minimum of 15ms which is our entire frame budget

Release Notes:

- N/A *or* Added/Fixed/Improved ...

There was a `when()` condition here looking at
`hovered_edited_file_buttons`, which is never turned to true when
hovering over the edited file button, and given we started to pass the
hover styles, tooltip, and on_click handler inside the condition, they
would never work. The solution here is to make these three things
unconditional, so edited files are always clickable.

Release Notes:

- N/A

Release Notes:

- N/A

Release Notes:

- N/A

This language is used for the keymap editor and should not be selectable
for normal files. Hence, removing it here from the language selector

Release Notes:

- Fixed an issue where the Zed keybinding context would show up as a
language in the language selector.

Release Notes:

- N/A

- Keyboard navigation where you can traverse through cells using up and
down arrow
- Jupyter Logo added 
- Initialize kernel as shutdown for more predictable behavior
- Ability to create .ipynb files with bare essential metadata.
- Optimize editor initialization to avoid cloning the entire notebook
and shortcuts


Release Notes:

- N/A

---------

Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

## Summary

Adds documentation for the `git_hosting_providers` setting that allows
users to configure custom self-hosted Git instances for clickable links.

## Description

This PR documents the previously undocumented `git_hosting_providers`
setting in the Git integration documentation. The setting allows users
to configure Zed to recognize and create clickable links to issues, pull
requests, and commits on self-hosted Git instances (like company GitLab
or GitHub Enterprise servers).

## Fixes

Closes #38433

## Test Plan

- Documentation follows the existing style and tone of `docs/src/git.md`
- Placement in the "Git Integrations" section makes logical sense
- Code example matches the format confirmed working by maintainers in
the issue

Release Notes:

- Improved: Documented the `git_hosting_providers` setting for
configuring custom self-hosted Git instances

---------

Co-authored-by: MrSubidubi <finn@zed.dev>

Release Notes:

- N/A

Release Notes:

- acp: Support ACP Session Config options for agents which provide them.

Release Notes:

- N/A

Fixes #48231

## Problem
When debugging Rust programs with CodeLLDB, panic breakpoints ("Rust: on
panic") don't work unless `sourceLanguages: ["rust"]` is explicitly set
in the debug configuration.

Without this setting, CodeLLDB doesn't return the `rust_panic` exception
filter, so the breakpoint shows `locations = 0 (pending)` and never
triggers.

## Root Cause
The Cargo locator correctly adds `sourceLanguages: ["rust"]`
([cargo.rs:97-100](https://github.com/zed-industries/zed/blob/main/crates/project/src/debugger/locators/cargo.rs#L97-L100)),
but other code paths may not:
- VSCode launch.json imports
- Manual debug configurations

## Solution
Auto-detect Rust binaries in `CodeLldbDebugAdapter::get_binary()` by
checking if the program path contains `/target/debug/` or
`/target/release/` (Cargo's standard output directories).

If detected and `sourceLanguages` isn't already set, we automatically
add `["rust"]`.

Release Notes:

- Fixed Rust panic breakpoints not working in debugger when using
CodeLLDB with non-Cargo debug configurations

When using gzip, the output path's extension becomes `.gz`.

Release Notes:

- N/A

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>

Release Notes:

- Allow closing notification toasts via middle mouse clicks

Release Notes:

- N/A

This PR adds a page in the settings UI, under the AI section, that
allows to interact and customize permissions for tool calling for each
tool available to Zed's native agent.

Release Notes:

- AI: Added a settings page in the settings editor that allows to
customize tool call permissions for each tool.

---------

Co-authored-by: Richard Feldman <oss@rtfeldman.com>

This way, you can configure external EP providers from the EP menu.

Release Notes:

- N/A

Release Notes:

- N/A

Previously, Ollama would not show up as available until you opened some
UI that prompted connecting to Ollama, like the agent panel or the edit
prediction settings.

Release Notes:

- N/A

`spacer_blocks` is an ideal place to drop `WrapPointCursor` since a
large part of what it does it to convert an increasing sequence of
`MultiBufferPoint` into `WrapPoint`.

Release Notes:

- N/A

This PR removes the Postgres and `stripe-mock` contains from the Docker
Compose cluster, as these now run in Cloud's Docker Compose cluster.

Release Notes:

- N/A

Release Notes:

- N/A

The side-by-side diff heavily relies on a primitive from `buffer_diff`
that converts a point on one side of the diff to a range of points on
the other side. The way this primitive is set up on main is pretty
naive--every time we call `points_to_base_text_points` (or
`base_text_points_to_points`), we need to iterate over all hunks in the
diff. That's particularly bad for the case of constructing a new
side-by-side diff starting from a multibuffer, because we call those
APIs once per excerpt, and the number of excerpts is ~equal to the
number of hunks.

This PR changes the point translation APIs exposed by `buffer_diff` to
make it easier to use them efficiently in `editor`. The new shape is a
pair of functions that return a patch that can be used to translate from
the main buffer to the base text or vice versa. When syncing edits
through the block map that touch several excerpts for the same buffer,
we can reuse this patch for excerpts after the first--so when building a
new side-by-side diff, we'll iterate over each hunk just once.

The shape of the new APIs also sets us up to scale down to cases like
editing on the right-hand side of the diff: we can pass in a point range
and give them permission to return an approximate patch that's only
guaranteed to give the correct results when used with points in that
range. For edits that only affect one excerpt, and given how the project
diff is set up, that should allow us to skip iterating over most of the
hunks in a buffer.

Release Notes:

- N/A

---------

Co-authored-by: cameron <cameron.studdstreet@gmail.com>

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

Release Notes:

- Added the ability to use Ollama as an edit prediction provider

---------

Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>

This PR re-enables docs deployments.

The upstream incident has been resolved:
https://www.cloudflarestatus.com/incidents/m1xvmqf37z97

Release Notes:

- N/A

Closes #46780

Creates a better flow for handling errors when a devcontainer fails, by
shortening the message and giving the user a direct route to the Zed
log. Additionally, the error from `stderr` is printed with proper line
endings, making the log more legible

<img width="1716" height="1093" alt="Screenshot 2026-02-03 at 2 54
50 PM"
src="https://github.com/user-attachments/assets/08d7847b-c9b8-49e9-9936-6ae417f82fb2"
/>
<img width="1711" height="908" alt="Screenshot 2026-02-03 at 2 55 07 PM"
src="https://github.com/user-attachments/assets/a2676419-a118-432e-8e8a-32c6e92f4f3b"
/>
<img width="2901" height="542" alt="Screenshot 2026-02-03 at 2 55 48 PM"
src="https://github.com/user-attachments/assets/ea9de533-c1c6-4cb7-bd79-e44bd035537c"
/>


Release Notes:

- Improved error messaging and handling in the event of a devcontainer
launch failure

Currently, each time we draw a primitive batch, we fully overwrite the
instance buffer with the contents of the new batch. Since we use a
write-only mapping to do this, the GPU driver may handle synchronization
hazards by transparently creating new allocations if the previous
allocation is still in use. We draw many primitive batches in one frame,
which stress-tests this mechanism somewhat. If internal driver limits
are hit, the resource update will start to block until the GPU catches
up and releases in-use allocations. This would result in a significant
reduction in framerate.

To avoid this, we upload the data for all primitive batches at once at
the beginning of the frame. Each primitive batch draw then binds the
relevant sub-array of the instance buffer. This way, there are no
mid-frame resource updates.

Release Notes:

- N/A

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [jsonwebtoken](https://redirect.github.com/Keats/jsonwebtoken) |
workspace.dependencies | major | `9.3` → `10.0` |

---

> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.

### GitHub Vulnerability Alerts

####
[GHSA-h395-gr6q-cpjc](https://redirect.github.com/Keats/jsonwebtoken/security/advisories/GHSA-h395-gr6q-cpjc)

## Summary:

It has been discovered that there is a Type Confusion vulnerability in
jsonwebtoken, specifically, in its claim validation logic.

When a standard claim (such as nbf or exp) is provided with an incorrect
JSON type (Like a String instead of a Number), the library’s internal
parsing mechanism marks the claim as “FailedToParse”. Crucially, the
validation logic treats this “FailedToParse” state identically to
“NotPresent”.

This means that if a check is enabled (like: validate_nbf = true), but
the claim is not explicitly marked as required in required_spec_claims,
the library will skip the validation check entirely for the malformed
claim, treating it as if it were not there. This allows attackers to
bypass critical time-based security restrictions (like “Not Before”
checks) and commit potential authentication and authorization bypasses.

## Details:

The vulnerability stems from the interaction between the TryParse enum
and the validate function in
[src/validation.rs](https://redirect.github.com/Keats/jsonwebtoken/blob/master/src/validation.rs).

1. The TryParse Enum: The library uses a custom TryParse enum to handle
claim deserialization:
```
enum TryParse<T> {
    Parsed(T),
    FailedToParse, // Set when deserialization fails (e.g. type mismatch)
    NotPresent,
}
```
If a user sends {“nbf”: “99999999999”} (legacy/string format), serde
fails to parse it as u64, and it results in TryParse::FailedToParse.

1. The Validation Logic Flaw (src/validation.rs): In
Validation::validate, the code checks for exp and nbf
like this:
```
// L288-291
if matches!(claims.nbf, TryParse::Parsed(nbf) if options.validate_nbf && nbf > now + options.leeway) {
    return Err(new_error(ErrorKind::ImmatureSignature));
}
```
This matches! macro explicitly looks for TryParse::Parsed(nbf).

 • If claims.nbf is FailedToParse, the match returns false.
 • The if block is skipped.
 • No error is returned.
1. The “Required Claims” Gap: The only fallback mechanism is the
“Required Claims” check:
```
// Lines 259-267
for required_claim in &options.required_spec_claims {
    let present = match required_claim.as_str() {
        "nbf" => matches!(claims.nbf, TryParse::Parsed(_)),
        // ...
    };
    if !present { return Err(...); }
}
```
If “nbf” IS in required_spec_claims, FailedToParse will fail the
matches!(..., Parsed(_)) check, causing the present to be false, and
correctly returning an error.

However, widely accepted usage patterns often enable validation flags
(validate_nbf = true) without adding the claim to the required list,
assuming that enabling validation implicitly requires the claim’s
validity if it appears in the token. jsonwebtoken seems to violate this
assumption.

Environment:

 • Version: jsonwebtoken 10.2.0
 • Rust Version: rustc 1.90.0
 • Cargo Version: cargo 1.90.0
 • OS: MacOS Tahoe 26.2

POC:

For demonstrating, Here is this simple rust code that demonstrates the
bypass. It attempts to validate a token with a string nbf claiming to be
valid only in the far future.

create a new project:
```
cargo new nbf_poc; cd nbf_poc
```
add required dependencies:
```
cargo add serde --features derive
cargo add jsonwebtoken --features rust_crypto
cargo add serde_json
```
replace the code in src/main.rs with this:

```
use jsonwebtoken::{decode, Validation, Algorithm, DecodingKey, Header, EncodingKey, encode};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    nbf: String, // Attacker sends nbf as a String
    exp: usize,
}
fn main() {
    let key: &[u8; 24] = b"RedMouseOverTheSkyIsBlue";

    // nbf is a String "99999999999" (Far future)
    // Real nbf should be a Number.
    let my_claims: Claims = Claims {
        sub: "krishna".to_string(),
        nbf: "99999999999".to_string(), 
        exp: 10000000000, 
    };

    let token: String = encode(&Header::default(), &my_claims, &EncodingKey::from_secret(key)).unwrap();
    println!("Forged Token: {}", token);

    // 2. Configure Validation
    let mut validation: Validation = Validation::new(Algorithm::HS256);
    validation.validate_nbf = true; // Enable NBF check

    // We do NOT add "nbf" to required_spec_claims (default behavior)

    // We decode to serde_json::Value to avoid strict type errors in our struct definition hiding the library bug.
    // The library sees the raw JSON with string "nbf".
    let result: Result<jsonwebtoken::TokenData<serde_json::Value>, jsonwebtoken::errors::Error> = decode::<serde_json::Value>(
        &token, 
        &DecodingKey::from_secret(key), 
        &validation
    );

    match result {
        Ok(_) => println!("Token was accepted despite malformed far-future 'nbf'!"),
        Err(e) => println!("Token rejected. Error: {:?}", e),
    }
}
```
run cargo run

expected behaviour:

```
Forged Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJrcmlzaG5hIiwibmJmIjoiOTk5OTk5OTk5OTkiLCJleHAiOjEwMDAwMDAwMDAwfQ.Fm3kZIqMwqIA6sEA1w52UOMqqnu4hlO3FQStFmbaOwk
```
Token was accepted despite malformed far-future 'nbf'!
Impact:

If an application uses jsonwebtoken nbf (Not Before) to schedule access
for the future (like “Access granted starting tomorrow”).

By sending nbf as a string, an attacker can bypass this restriction and
access the resource immediately.

and for the exp claim (this is unlikely but still adding), If a
developer sets validate_exp = true but manually handles claim presence
(removing exp from required_spec_claims), an attacker can send a string
exp (e.g., “never”) and bypass expiration checks entirely. The token
becomes valid forever.

---

### Release Notes

<details>
<summary>Keats/jsonwebtoken (jsonwebtoken)</summary>

###
[`v10.3.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1030-2026-01-27)

[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v10.2.0...v10.3.0)

- Export everything needed to define your own CryptoProvider
- Fix type confusion with exp/nbf when not required

###
[`v10.2.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1020-2025-11-06)

[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v10.1.0...v10.2.0)

- Remove `Clone` bound from decode functions

###
[`v10.1.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1010-2025-10-18)

[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v10.0.0...v10.1.0)

- add `dangerous::insecure_decode`
- Implement TryFrom \&Jwk for DecodingKey

###
[`v10.0.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1000-2025-09-29)

[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v9.3.1...v10.0.0)

- BREAKING: now using traits for crypto backends, you have to choose
between `aws_lc_rs` and `rust_crypto`
- Add `Clone` bound to `decode`
- Support decoding byte slices
- Support JWS

</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:eyJjcmVhdGVkSW5WZXIiOiI0Mi45NS4yIiwidXBkYXRlZEluVmVyIjoiNDIuOTUuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->

---------

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

Follow-up to https://github.com/zed-industries/zed/pull/48209 - those
hardcoded rules are replacing these default settings, which will make
the rules clearer by removing the "override" scenario.

(No release notes because granular tool permissions are still behind a
feature flag.)

Release Notes:

- N/A

Closes #48178

Release Notes:

- Fixed issue where certain keywords were incorrectly highlighted in TSX
files

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [bytes](https://redirect.github.com/tokio-rs/bytes) |
workspace.dependencies | minor | `1.10.1` → `1.11.1` |

---

> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.

### GitHub Vulnerability Alerts

####
[GHSA-434x-w66g-qw3r](https://redirect.github.com/tokio-rs/bytes/security/advisories/GHSA-434x-w66g-qw3r)

# Details

In the unique reclaim path of `BytesMut::reserve`, the condition
```rs
if v_capacity >= new_cap + offset
```
uses an unchecked addition. When `new_cap + offset` overflows `usize` in
release builds, this condition may incorrectly pass, causing `self.cap`
to be set to a value that exceeds the actual allocated capacity.
Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted
`cap` value and may create out-of-bounds slices, leading to UB.

This behavior is observable in release builds (integer overflow wraps),
whereas debug builds panic due to overflow checks.

## PoC

```rs
use bytes::*;

fn main() {
    let mut a = BytesMut::from(&b"hello world"[..]);
    let mut b = a.split_off(5);

    // Ensure b becomes the unique owner of the backing storage
    drop(a);

    // Trigger overflow in new_cap + offset inside reserve
    b.reserve(usize::MAX - 6);

    // This call relies on the corrupted cap and may cause UB & HBO
    b.put_u8(b'h');
}
```

# Workarounds

Users of `BytesMut::reserve` are only affected if integer overflow
checks are configured to wrap. When integer overflow is configured to
panic, this issue does not apply.

---

### Release Notes

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

###
[`v1.11.1`](https://redirect.github.com/tokio-rs/bytes/blob/HEAD/CHANGELOG.md#1111-February-3rd-2026)

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

- Fix integer overflow in `BytesMut::reserve`

###
[`v1.11.0`](https://redirect.github.com/tokio-rs/bytes/blob/HEAD/CHANGELOG.md#1110-November-14th-2025)

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

- Bump MSRV to 1.57
([#&#8203;788](https://redirect.github.com/tokio-rs/bytes/issues/788))

##### Fixed

- fix: `BytesMut` only reuse if src has remaining
([#&#8203;803](https://redirect.github.com/tokio-rs/bytes/issues/803))
- Specialize `BytesMut::put::<Bytes>`
([#&#8203;793](https://redirect.github.com/tokio-rs/bytes/issues/793))
- Reserve capacity in `BytesMut::put`
([#&#8203;794](https://redirect.github.com/tokio-rs/bytes/issues/794))
- Change `BytesMut::remaining_mut` to use `isize::MAX` instead of
`usize::MAX`
([#&#8203;795](https://redirect.github.com/tokio-rs/bytes/issues/795))

##### Internal changes

- Guarantee address in `slice()` for empty slices.
([#&#8203;780](https://redirect.github.com/tokio-rs/bytes/issues/780))
- Rename `Vtable::to_*` -> `Vtable::into_*`
([#&#8203;776](https://redirect.github.com/tokio-rs/bytes/issues/776))
- Fix latest clippy warnings
([#&#8203;787](https://redirect.github.com/tokio-rs/bytes/issues/787))
- Ignore `BytesMut::freeze` doctest on wasm
([#&#8203;790](https://redirect.github.com/tokio-rs/bytes/issues/790))
- Move `drop_fn` of `from_owner` into vtable
([#&#8203;801](https://redirect.github.com/tokio-rs/bytes/issues/801))

</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:eyJjcmVhdGVkSW5WZXIiOiI0Mi45NS4yIiwidXBkYXRlZEluVmVyIjoiNDIuOTUuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->

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

Waiting is usually followed by “for,” which would make the label too
wordy. Awaiting is transitive and requires a direct object, in this case
your confirmation.

Really not a crazy change, but something that has been bothering me for
quite some time now. 😅

Release Notes:

- Improved wording of confirmation label text in agent thread