test(DataHandler): cover deeply nested reply causing decoder stack overflow

[GiHoon1123]

Fixes #2108.

redis-parser (and its replacement, the RESP3 Decoder from #2127) recurses
once per level of RESP aggregate nesting with no depth limit, so a
sufficiently deeply nested reply throws a RangeError instead of reporting a
parser error.

#2127 already wraps the decoder call in try/catch and routes failures
through the existing returnFatalError -> recoverFromFatalError path, so
this no longer needs a code change. There was no test pinning that behavior
down for this specific case, so this adds one.

Verified by temporarily removing the try/catch and confirming the new test
fails with the expected RangeError.

---

Note

Low Risk
The change is narrowly scoped defensive error handling around inbound parsing; the diff here is test-only, with production behavior already aligned to the existing fatal-recovery path.

Overview
This PR’s visible diff adds a regression test in DataHandler for issue #2108: feeding a reply nested ~50,000 *1 arrays must not throw synchronously and must invoke recoverFromFatalError once with a RangeError (“Maximum call stack size exceeded”) and { offlineQueue: false }.

The accompanying fix (described in the PR, not in the snippet above) wraps stream decoder.write in try/catch and forwards unexpected errors through the existing returnFatalError → recoverFromFatalError path so parser stack overflows recover instead of killing the Node process.

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

[PavelPashov]

@GiHoon1123 thank you for this PR, I'll take a look, however please check #2127 as it might make sense to adapt the change for that PR.

[GiHoon1123]

Thanks for the pointer! I took a look at #2127 — its DataHandler.ts already wraps decoder.write() in a try/catch that routes into returnFatalError the same way, so this exact crash looks like it's already handled there for the new RESP3 decoder path.

Since #2127 is still in progress, this PR still seemed worth having as a fix for the currently released behavior - main still calls redis-parser directly with no such guard. Happy to close this in favor of #2127 once it lands, or adjust the scope here if you'd prefer a different approach - whichever is more useful, just let me know.

[PavelPashov]

Thanks, looks good