fix(client): stabilize flaky LATENCY LATEST test

[nkaradzhov]

This pull request fixes a flaky client.latencyLatest test in packages/client/lib/commands/LATENCY_LATEST.spec.ts.

The bug

The test issued DEBUG SLEEP 1, blocking the server for a full second. Combined with connection setup and the flushAll calls the harness runs before/after each test, this left little headroom under mocha's 2000ms default timeout. On loaded CI runners it intermittently exceeded the timeout:

Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
  (packages/client/lib/commands/LATENCY_LATEST.spec.ts)

The fix

Halve the sleep to 0.5 (500ms). It still comfortably exceeds the latency-monitor-threshold of 100ms, so a latency event is still recorded and the assertions remain meaningful, while roughly doubling the non-sleep budget under the 2000ms timeout. This matches the pattern in sibling specs (LATENCY_RESET.spec.ts uses DEBUG SLEEP 0.1 against a 1ms threshold).

Locally the test now completes in ~550ms.

🤖 Generated with Claude Code

---

Note

Low Risk
Test-only timing tweak with no production or client API changes.

Overview
Reduces the Redis DEBUG SLEEP duration in the client.latencyLatest integration test from 1s to 0.5s so the case stays under Mocha’s default 2000ms timeout on slow CI, where harness setup and flushAll left little margin after a full-second block.

The 100ms latency-monitor-threshold is unchanged, so 500ms sleep still triggers latency events and the existing shape assertions stay valid—aligned with shorter sleeps used in other LATENCY specs (e.g. LATENCY_RESET).

^{Reviewed by Cursor Bugbot for commit c6f4f68. Bugbot is set up for automated code reviews on this repo. Configure here.}