Unrolled build for #144452

Rollup merge of #144452 - morinmorin:apple/update_read_limit, r=ChrisDenton

std/sys/fd: Relax `READ_LIMIT` on Darwin

Darwin's `read`/`write` syscalls emit `EINVAL` only when `nbyte > INT_MAX`. The case `nbyte == INT_MAX` is valid, so the subtraction (`- 1`) in
```rust
const READ_LIMIT: usize = if cfg!(target_vendor = "apple") {
    libc::c_int::MAX as usize - 1 // <- HERE
} else {
    libc::ssize_t::MAX as usize
};
```
can be removed.

I tested that the case `nbyte == INT_MAX` is valid on various versions of macOS, including old one like Mac OS X 10.5.

The man page says:
- read() and pread() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/read.2.html)
- write() and pwrite() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/write.2.html)

Here are links to Darwin's code:
- [macOS 15.5] https://github.com/apple-oss-distributions/xnu/blob/e3723e1f17661b24996789d8afc084c0c3303b26/bsd/kern/sys_generic.c#L307
- [Mac OS X 10.2] https://github.com/apple/darwin-xnu/blob/d738f900846ed2d5f685e18bf85ce63b0176f61a/bsd/kern/sys_generic.c#L220

Related PR: #38622.

Author: rust-timer

library/std/src/sys/fd/unix.rs

@@ -37,10 +37,10 @@ pub struct FileDesc(OwnedFd);
 //
 // On Apple targets however, apparently the 64-bit libc is either buggy or
 // intentionally showing odd behavior by rejecting any read with a size
-// larger than or equal to INT_MAX. To handle both of these the read
-// size is capped on both platforms.
+// larger than INT_MAX. To handle both of these the read size is capped on
+// both platforms.
 const READ_LIMIT: usize = if cfg!(target_vendor = "apple") {
-    libc::c_int::MAX as usize - 1
+    libc::c_int::MAX as usize
 } else {
     libc::ssize_t::MAX as usize
 };