Fix pub/sub message delivery to idle subscribers (v0.11.9)

[mack42]

Bug

A subscriber never received a published message until it happened to send another byte to the server. Any client that subscribes and then waits passively (the normal pub/sub pattern) missed messages.

Root cause

In src/server/connection.rs, the handle() loop latches in_pubsub once at the top of each iteration:

loop {
    let in_pubsub = ...;               // latched here
    if in_pubsub { /* select! read_buf OR pubsub_rx */ }
    else {
        while let Some(r) = try_process_command() { write }   // SUBSCRIBE handled here
        let n = read_buf(...);         // then blocks on the socket
    }
}

When a fresh subscriber's SUBSCRIBE is processed, it happens inside the else branch (because in_pubsub was false when the iteration began). Control then falls through to the blocking read_buf — not the select! — so pubsub_rx is never polled. The published message is delivered into the channel (that's why PUBLISH correctly returns :1) but nothing drains it until the next loop iteration, which only happens when the client sends more data.

Reproduced with a raw RESP client: the message frame arrived only after poking the subscriber socket with an unrelated PING.

(The earlier idle-read timeout reduced the symptom from "hangs forever" to "delivered after 30s", still well past the tests' 5s wait.)

Fix

After the normal-mode command loop, re-enter the loop if the connection has just entered pub/sub mode, so the next iteration waits on the select! that watches pubsub_rx:

if !self.subscribed_channels.is_empty() || !self.subscribed_patterns.is_empty() {
    continue;
}

Verification

• Manual raw-RESP reproduction: message now arrives immediately, no poke needed.
• cargo test full suite green (87 unit + all integration), including the two pubsub tests that previously failed.

Also commits the integration test suite (tests/), previously untracked — the two pubsub tests exercised exactly this bug and now pass, so they're worth keeping as regression coverage.