fix(iouring): do not mark a conn recv-paused when the cancel was never submitted

[FumingPower3925]

The defect

drainDetachQueue takes a bare w.ring.GetSQE() for the WebSocket recv-pause cancel, then assigns cs.recvPaused = desired unconditionally, outside the if sqe != nil block:

if desired := cs.recvPauseDesired.Load(); desired != cs.recvPaused {
    if desired {
        if sqe := w.ring.GetSQE(); sqe != nil {   // ← no retry
            prepCancelUserDataSkipSuccess(...)
        }                                         // ← nil: nothing submitted
    } else {
        ... prepareRecv ...
    }
    cs.recvPaused = desired                       // ← set anyway
}

When the submission ring is full the cancel is never submitted, but the connection is recorded as paused while its multishot recv is still kernel-armed. The matching resume then sees desired=false != recvPaused=true, takes the re-arm branch, and calls prepareRecv — arming a second multishot recv on the same socket. Two armed recvs deliver interleaved data.

Nothing retried either. PauseRecv enqueues only on the false→true transition of recvPauseDesired, and that flag is already true by the time the drain runs, so a dropped pause was lost silently rather than reattempted.

The fix

Use getCancelSQE() — which submits and retries once when the ring is full — the form the close path already uses in the same file. Record the paused state only when the cancel actually went in, and re-enqueue the connection so the next drain retries.

The pause path is reachable only from WebSocket backpressure, so this is io_uring-only and WS-only. Epoll applies the same pause as a synchronous EPOLL_CTL_MOD that cannot be dropped and has no op to double-arm.

Regression guard

middleware/websocket/detach_residual_heap_linux_test.go — engine-parameterized, asserts residual heap across detached-connection teardown on both HeapAlloc and HeapInuse, so retention and span slack are distinguished.

It drives the validator's own RFC-6455 abuse modes (invalid UTF-8, unmasked client, continuation-without-start, reserved bits, ping flood) so teardown is server-initiated, which is the shape real traffic takes. An earlier draft closed from the client instead and passed trivially on a path that leaks nothing — worth knowing if this test is ever revised.

Measured on msa2-server (amd64, kernel 7.0.0-30), 3000 detaches per mode, HeapAlloc bytes per detach:

mode	epoll	io_uring
invalid-utf8	28.1	2.5
unmasked-client	12.9	−3.5
continuation-no-start	1.1	−1.3
fragmented-reserved	2.2	4.5
ping-flood	−0.8	−2.6

Scope — please read before merging

This was written to reproduce the v1.5.11 24h soak's I-MEM-1 failure (2.4–2.7 KB/s heap trough slope on auth_session_ratelimit × io_uring, both architectures, ~156 B/detach). It does not reproduce it, as the table above shows.

So this PR fixes a real, independently verified defect on its own correctness merits. It does not claim to fix the soak failure, whose cause remains unestablished. Do not treat merging this as clearing the gate.

Verification

• go build ./..., go vet ./engine/iouring/ clean.
• engine/iouring full suite: PASS on msa2-server amd64.
• middleware/websocket suite (incl. the celeris#482 regression guard TestBackpressurePauseDoesNotCancelInflightSend): PASS.
• New guard: 10/10 sub-tests PASS across both engines.