A cancel message that goes through the same work queue as the requests it cancels arrives too late; handle cancels out-of-band

Seen in an interactive app talking to a worker-pool backend over a request/response channel: the UI issued 4 small 'find next/previous change' requests, then cancelled and re-issued them when the user moved the cursor. The network log showed the cancels sent at 1.8 s returning at 6.1 s, after the requests they were meant to cancel. The cancel was a normal message: it entered the same FIFO as the bulk reads ahead of it (each about 3 s) and got handled in turn. Meanwhile the re-issued requests queued behind the same bulk work, and the cursor took about 11 s to show a value.

Fixes that apply generally: 1. Handle control messages (cancel, priority change, ping) in the receive loop the moment they arrive, before anything is enqueued. A cancel marks the request id cancelled. Queued tasks with that id are dropped when dequeued, and a running task checks the flag between pieces. 2. Give small interactive requests their own lane (a separate queue or a reserved worker), so they never wait behind bulk reads. Bulk work goes through a bounded queue, in pieces that yield between them. 3. Coalesce re-issued requests: if the same query (same key) is already queued or running, attach the new caller to it instead of queueing a duplicate. Mind the inverse: never attach a foreground caller to a background job's load. 4. Measure per request id: time sent, time queued, time running, time replied, and which worker served it. With that, a slow cancel shows up immediately; end-to-end timings only show that 'it's slow'. 5. Test: a stub backend with slow bulk tasks in the queue. Send cancel(id) and assert the ack arrives within a few ms and the task never runs. Send a small request and assert its latency is about the same as on an idle backend.