perf(libs/core): drop libuv-style partial-read break to fix node:http p99 - #33860

… p99

`poll_tcp_handle`'s read loop matched libuv's `uv__read` by breaking
on partial reads (`n < buf.len`) to skip the predicted-EAGAIN syscall.
That's correct for libuv's epoll loop, but wrong against tokio: tokio's
`TcpStream` readiness is edge-triggered and the internal "readable"
bit is cleared only by a `WouldBlock` from `try_read`. Breaking on a
partial read left the bit armed, the re-register block at the end of
the function then saw `poll_read_ready == Ready`, and `mark_ready()`
put the handle right back on the loop's ready queue and woke
`loop_waker`.

Under sustained HTTP keep-alive load with small responses every read
is partial, so every tick re-queued every active connection. Tokio's
current_thread runtime saw the deno task continuously awoken and
never yielded to its reactor (controlled by `event_interval`, default
61). New TCP readiness from the kernel piled up undelivered and each
connection waited a full event_interval window before its next
request was processed.

The fix is one line: keep looping until `try_read` actually returns
`WouldBlock`. That costs one extra `recv()` syscall when the read
fully drains the socket buffer, but the syscall returns `WouldBlock`,
clears tokio's readiness bit, and the handle drops out of the ready
queue cleanly. The reactor is then free to deliver fresh wakes.

100-connection oha bench against `node:http` hello-world
(`release-lite`):

|         | node    | deno before | deno after |
| ------- | ------- | ----------- | ---------- |
| p50     | 1.26 ms | 0.96 ms     | 1.58 ms    |
| p99     | 2.56 ms | 33.4 ms     | 3.14 ms    |
| p99.9   | 4.26 ms | 60.7 ms     | 6.34 ms    |
| p99.99  | 7.28 ms | 68.0 ms     | 8.28 ms    |

`Deno.serve` p99 unchanged (1.31 ms; no regression).

The MSG_PEEK probe in `poll_tcp_handle`'s write path fired when reads
weren't active and treated `n == 0` (peer FIN) the same as a read
error: it drained the entire write queue with EPIPE.

Before the partial-read break was removed, `internal_reading` rarely
became false during normal traffic so this path almost never ran.
Removing the partial-read break (so the read loop runs to WouldBlock
and clears `internal_reading` cleanly on EOF) exposed the bug:
test-net-allow-half-open's second case writes after the peer half-
closes, and now hit `Uncaught Error: write EPIPE`.

Treating EOF as "connection broken" is wrong. TCP half-close is
valid: a peer can send FIN and still keep its read side open. Only
RST or other recv() errors mean the connection is unusable for
writes. The probe still detects those — `n < 0` with a non-WouldBlock
errno still drains pending writes with EPIPE — but `n == 0` is now
treated as benign half-close. The actual EOF is reported through the
normal read path.

Reverts the n=0 portion of the prior fix on Windows only.

libuv on Windows uses async writes via WSASend with overlapped
I/O; uv__process_tcp_write_req surfaces broken-pipe errors
through the IOCP completion. tokio's try_write_vectored (used
by our uv_compat write loop) is synchronous send(): when the
peer is gone, the local kernel can still queue bytes and report
success, and the broken state only surfaces on a later send/recv
after the OS notices the RST. By the time it does, the test's
auto-shutdown after read EOF has already closed the socket and
the process has exited without raising the expected 'error'
event (test-net-error-twice.js relies on this signal).

Mimic libuv's IOCP-driven error delivery on Windows by keeping
the n == 0 → drain-with-EPIPE branch of the existing MSG_PEEK
probe. On unix, n == 0 (peer FIN) remains a benign half-close —
tokio's send returns ECONNRESET / EPIPE directly when the
connection is actually broken.

Reorder poll_tcp_handle so the write loop runs before the
broken-connection probe, and only run the probe when the write loop
actually hit WouldBlock with a non-empty residual queue. Small writes
queued behind a peer FIN (e.g. test-net-allow-half-open's 3-byte
'asd') drain in one pass and skip the probe entirely, while large
stuck queues whose peer is gone (test-net-error-twice's 10MB write
on Windows) still get the EPIPE drain they need.

Use a per-connection "ever received data" flag as the probe gate,
replacing the WouldBlock + !internal_reading combo. This distinguishes
the test-net-allow-half-open scenario (peer sends 1024 bytes before
FIN — received_data=true, probe skipped, queued 'asd' write completes)
from test-net-error-twice (peer destroys without writing —
received_data stays false, probe fires).

On Windows, also retroactively flip the most recent successful write
to EPIPE when the probe trips. Windows' kernel send buffer can absorb
large writes silently (auto-tuning grows it past 10 MB on loopback),
so the queue may have already drained to "successful" by the time the
probe runs — without the flip, the broken-connection error libuv
would have reported via overlapped IOCP completion is lost entirely.