feat(client): support Uint8Array for blob string decoding

[raashish1601]

Test

---

Note

Low Risk
Decoder and XINFO GROUPS changes are localized with tests; remaining edits are TypeScript typing defaults and aliases.

Overview
Adds Uint8Array as a type-mapping target for RESP simple and bulk strings via a shared #decodeStringType helper (views over the underlying buffer, including multi-chunk bulk strings), with decoder tests.

XINFO GROUPS RESP2 handling is fixed: last-delivered-id is typed as a string, Redis 7 lag/entries-read allow null, and reply shaping uses transformTuplesReply instead of hard-coded tuple indices, with new unit tests.

Typing-only updates thread generics through EnterpriseMaintenanceManager, RedisClientOptions (default RESP is 2), sentinel BroadSentinelClient / PubSubProxy<RESP>, and test-utils cleanupAclUsers—no intended runtime behavior change there.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 105bc16. Configure here.}

[cursor]

Uint8Array view leaks shared Buffer pool data

Medium Severity

#decodeStringType creates a Uint8Array view into the Buffer's underlying ArrayBuffer via new Uint8Array(chunk.buffer, chunk.byteOffset, chunk.byteLength). In Node.js, small Buffers (including those from Buffer.concat, subarray, etc.) share a pooled ArrayBuffer (~8 KB). The returned Uint8Array's .buffer property exposes the entire pool — which may contain data from other Redis responses — and prevents garbage collection of the pool. Users passing result.buffer to web APIs (e.g. postMessage, WebSocket.send) or using ArrayBuffer.transfer() would encounter data leakage or corruption. Using new Uint8Array(chunk) instead would produce a copy with an independent ArrayBuffer.

 

^{Reviewed by Cursor Bugbot for commit 105bc16. Configure here.}

[nkaradzhov]

Duplicate of #3183