fix: update bytes from 1.10.1 to 1.11.1 (RUSTSEC-2026-0007) (#5099)

### What problem does this PR solve?

Problem Summary:

RUSTSEC-2026-0007: Integer overflow in `BytesMut::reserve` allows
unchecked addition of `new_cap + offset` to wrap in release builds,
corrupting capacity tracking and enabling out-of-bounds memory access.

### What is changed and how it works?

What's Changed:

- Bump `bytes` dependency from `1.10.1` to `1.11.1` in workspace
`Cargo.toml`
- Update `Cargo.lock` to reflect patched version

Version 1.11.1 adds overflow checks to the reserve path, preventing
capacity corruption.

### Related changes

- N/A

### Check List

Tests

- No code

Side effects

- N/A

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>RUSTSEC-2026-0007: Integer overflow in
`BytesMut::reserve`</issue_title>
> <issue_description>
> > Integer overflow in `BytesMut::reserve`
> 
> | Details | |
> | ------------------- | ----------------------------------------------
|
> | Package             | `bytes`                      |
> | Version             | `1.10.1`                   |
> | URL |
[https://github.com/advisories/GHSA-434x-w66g-qw3r](https://github.com/advisories/GHSA-434x-w66g-qw3r)
|
> | Date                | 2026-02-03                         |
> | Patched versions    | `>=1.11.1`                  |
> | Unaffected versions | `<1.2.1`               |
> 
> In the unique reclaim path of `BytesMut::reserve`, the condition
> ```rs
> if v_capacity &gt;= 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(&amp;b&quot;hello world&quot;[..]);
>     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 &amp; HBO
>     b.put_u8(b&#39;h&#39;);
> }
> ```
> 
> # 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.
> 
> See [advisory
page](https://rustsec.org/advisories/RUSTSEC-2026-0007.html) for
additional details.
> </issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes #5098

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: eval-exec <46400566+eval-exec@users.noreply.github.com>

Author: Copilot

Cargo.lock

@@ -137,7 +137,7 @@ blake2b-ref = "0.3"
 bloom-filters = "0.1"
 bs58 = "0.5.0"
 byteorder = "1.3.1"
-bytes = "1"
+bytes = "1.11.1"
 cfg-if = "1.0"
 ckb-app-config = { path = "util/app-config", version = "1" }
 ckb-async-runtime = { path = "util/runtime", version = "1" }