What does this PR do?

Fixes the dominant Windows crash family in Sentry: SEGV during full GC inside JSC::Heap::sweepArrayBuffers -> JSC::ArrayBuffer::~ArrayBuffer -> JSC::ArrayBufferContents::~ArrayBufferContents -> mi_free -> _mi_ptr_page / mi_validate_ptr_page (BUN-30T8, 8k+ events, plus siblings BUN-2WZN, BUN-2R90, BUN-2XNJ, BUN-33SN faulting while walking the GC incoming-ref set). Almost exclusively Windows, bun 1.3.11 through 1.3.14, workloads using fetch + spawn or plain CLI runs.

Root cause

WindowsBufferedReader hands libuv a pointer into _buffer's spare capacity (get_read_buffer_with_stable_memory_address). Two Windows read paths retain that pointer across event-loop iterations:

• Cooked-mode console reads (default for process.stdin / Bun.stdin.stream() on a console): libuv's uv__tty_queue_read_line stores the alloc_cb buffer and blocks a worker thread in ReadConsoleW. The worker converts the typed line into that buffer (uv_utf16_to_wtf8 into read_line_buffer.base) even when the read was cancelled mid-flight: uv_read_stop cancels asynchronously by injecting a VK_RETURN, and after read_stop the buffer is never handed back through read_cb.
• uv_fs_read: the threadpool worker writes through File.iov until the completion callback fires; uv_cancel only succeeds if the work item has not started.

Teardown freed or moved the allocation anyway:

• finish() called _buffer.shrink_to_fit(). For a streaming reader len == 0, so this frees the whole block while the console worker still targets it.
• deinit() and Drop dropped the Vec unconditionally.
• HAS_INFLIGHT_READ was cleared in finish()/_on_read_chunk, i.e. while the read was in fact still outstanding, so nothing downstream could even detect the retention.

The late worker write then lands in freed mimalloc memory and corrupts whatever was allocated there next. 8 KiB blocks are a prime size class for ArrayBuffer backing stores (fetch response bodies), so the corruption surfaces arbitrarily later as a GC-sweep crash: ~ArrayBufferContents runs mi_free on a clobbered data pointer, and _mi_ptr_page's release-build page-map lookup dereferences an uncommitted/NULL submap entry (fault addresses like 0x0000B1A0 are NULL[sub_idx]). macOS uses the checked _mi_ptr_page variant, which is why the family skews so heavily to Windows. The 1.3.x Zig implementation (src/io/PipeReader.zig: finish -> shrinkAndFree, deinit -> buffer().deinit()) has the identical defect; the Rust port carried it over unchanged.

Fix

Establish the invariant that _buffer's allocation is never freed or moved while libuv may still write into it:

• HAS_INFLIGHT_READ now means exactly "libuv may still write into _buffer". It is cleared only where the buffer provably came back: on_stream_read entry (pipe reads complete synchronously inside uv__pipe_read_data; a tty read_cb only fires after the reader thread finished) and on_file_read entry. The clears in finish() and _on_read_chunk are removed (the trailing _on_read_chunk clear could also clobber the flag of a read re-armed by a re-entrant callback).
• finish() skips shrink_to_fit while the flag is set.
• close_impl parks the buffer on the Box<File> (new File::retained_read_buffer field) when a file op is still operating/canceling at detach; the Box is freed in on_close_complete, strictly after the operation finished, so the buffer is reclaimed exactly rather than leaked.
• on_file_read now also consumes DEFER_DONE_CALLBACK when the read completes normally, i.e. when uv_cancel lost the race because the threadpool worker had already started. Previously only the UV_ECANCELED branch honored the deferred close, so the reader stayed paused forever with its File source attached and on_reader_done never fired (flagged by review).
• deinit()/Drop release the buffer through release_buffer_on_teardown(): freed normally when no read is pending, leaked when one is. Console reads after uv_read_stop have no completion signal left to observe, so the leak is unavoidable, but it is bounded to one spare-capacity buffer per torn-down reader and replaces heap corruption.
• take_buffer() copies out the committed bytes (disjoint from the region the worker writes) instead of handing the caller a retained allocation; FileReader::drain/consume_reader_buffer now go through it instead of mem::take(buffer()).

POSIX readers are untouched (PosixBufferedReader reads synchronously on the loop thread; no retention exists).

How did you verify your code works?

Test

test/js/bun/terminal/terminal-spawn.test.ts: "cancelling a parked console stdin read does not corrupt the heap" (Windows-only, uses Bun.Terminal/ConPTY so the child gets a real console). The child arms a cooked-mode stdin read, waits for the libuv worker to park in ReadConsoleW, cancels the stream (pre-fix: finish() frees the 8 KiB buffer while cancellation is in flight), immediately adopts the freed block with same-size ArrayBuffer probes (mimalloc serves freshly freed blocks of a size class first), and fails if the cancelled read's late "\r\n" write mutates a probe.

Caveats, stated plainly:

• The bug is unreachable on POSIX (the buggy code is #[cfg(windows)]), so the test skips there and cannot demonstrate fail-before on a Linux runner. Fail-before on Windows follows from the mechanism above (the VK_RETURN-cancelled read always performs the late write; detection depends on the freed block being reused by a probe, which mimalloc's free-list LIFO makes the overwhelmingly likely outcome).
• There is no deterministic repro for the production crash itself (no ASAN lane exists on Windows); this test exercises the exact teardown path and detects the stale write directly.

Verification done here: cargo check --workspace for x86_64-pc-windows-msvc and aarch64-pc-windows-msvc passes; on Linux, bun bd test passes for terminal-spawn.test.ts (new test skips), spawn.test.ts (115 pass), spawn-streaming-stdin.test.ts, process-stdin.test.ts, and streams.test.js (2 failures pre-exist on main, unrelated).

Possibly related issues (not claimed as fixed)

#26026 and #26862 match this corruption family's profile (Windows, long-running fetch/spawn/stdin workloads, delayed crashes at garbage addresses) but include no stacks to confirm the mechanism, so they are not auto-closed here. #27692 (flagged by the issue finder) reports kernel BSODs, which a user-mode use-after-free cannot cause; it is not addressed by this PR.