Zero freed slots before pooling/reslicing in clearLocked and delRequest

[linkdata]

Defects (second-pass per-package review)

Two low-severity GC-retention nits where a freed slice slot kept a stale reference live, each inconsistent with the deliberate reference-clearing already present in the same file.

1. clearLocked pools a Request without releasing wsQueue payloads (request.go)

clearLocked reset the outbound queue with rq.wsQueue = rq.wsQueue[:0], leaving the previous wire.WsMsg values — including Data, which carries full what.Inner/Replace/Append HTML payloads — live in the backing array of a Request returned to sync.Pool. A pooled Request can sit idle indefinitely, pinning those payloads until a future reuse overwrites each slot. This is inconsistent with the adjacent clear(rq.todoDirt) and clear(rq.elems) (both commented as releasing references before pooling) and with drainTailScript, which zeroes its freed slots.

2. delRequest leaves a stale *Request in the backing array (session.go)

The swap-remove copied requests[l-1] into the found index then resliced to [:l-1], but never nilled the vacated tail slot — so the backing array retained an otherwise-recyclable *Request (the duplicated one after a swap, or the original when removing the last element) for the session's lifetime.

Fix

• clear(rq.wsQueue) before the [:0] reslice (still under muQueue).
• sess.requests[l-1] = nil before reslicing.

Neither is a correctness bug — all iterators use the resliced length, so the stale entries are never observed — purely retention/consistency.

Tests

slotclear_test.go (internal package jaws) asserts the freed backing-array slots are zeroed: TestClearLockedZeroesWsQueue queues messages with payloads, runs clearLocked, and checks wsQueue[:cap] is all zero; TestDelRequestNilsVacatedSlot covers both the swap-remove and last-element paths. Both fail on the unpatched code.

Verification

go vet, gofumpt -l, staticcheck, go build, go test -race ./..., and go test -tags debug -race ./... all pass.