MQTT pingres timeouts under high load — verify on current build (RedHat)

**Investigative.** a customer reported a noticeable increase in MQTT `pingres` 30s timeouts after a 4.5.11 → 4.5.32 upgrade, causing disconnect/reconnect cycles. Correlated with high load. Expectation is that `pingres` should remain reliable as long as the server is running.

## Verify first

- Confirm whether this pattern still occurs on a current build (5.x). Substantial MQTT/server work has landed since 4.5.32.
- If still reproducible, capture: is the `pingres` sent later than the 30s timeout, or not sent at all?

## To investigate (if reproducible)

- The MQTT keepalive path: how is the response queued, and what could delay it past the 30s window?
- The compounding cost: each timeout triggers a disconnect + reconnect, which adds load — investigate whether the reconnect storm makes the underlying overload worse.
- Whether the MQTT server's pingres handling shares an event-loop or queue with general-purpose work that could starve it under load.

## Acceptance criteria (once verified)

- `pingres` round-trips within the keepalive window under load, or there's a documented backpressure path.
- Disconnect-reconnect storms under load are bounded (not exponentially compounding).

## Related

- Internal Slack: [thread](https://harperdb.slack.com/archives/C3Z2T1QAZ/p1762966557241939)

---

Tracked in Jira: [CORE-2954](https://harperdb.atlassian.net/browse/CORE-2954) (a customer customer escalation)
**Status:** Not Ready — needs verification on a current build before scoping engineering work.

🤖 Filed by Claude on behalf of Kris.