test(deepseek): stop pinning Node's one-shot zstd decoder to the first frame

The frame-walking test asserted that zlib.zstdDecompressSync returns only the first of 40 concatenated frames. That was true when the walker was written, but nodejs/node#65865 (shipped in 26.10.0 and in 24.22.0 LTS) makes Node decode every frame, so the assertion fails on current Node 24 LTS and 26 while the walker itself is still correct. The assertion tested Node, not Codeman: the walker's own 40-frame checks stay, and the comments now say which Node versions stop at the first frame, since the supported range (>=22) still includes them.

src/deepseek-transcript.ts

@@ -26,10 +26,11 @@
  * **1. One zstd FRAME per append, not one zstd stream.** The file is
  * `session.jsonl.zstd`, and dsh appends by compressing each batch of lines into
  * its own frame and writing it at the end. `zstd -dc` handles that (frames
- * concatenate by definition), but Node's `zlib.zstdDecompress()` and
- * `createZstdDecompress()` both stop at the first frame end: measured on a real
- * 56-line transcript, Node returned 158 bytes / 1 line where the CLI returned
- * 43,747 bytes / 56 lines. That is a silent truncation to the session header —
+ * concatenate by definition), but before Node 24.22 and 26.10
+ * (nodejs/node#65865) `zlib.zstdDecompress()` and `createZstdDecompress()` both
+ * stop at the first frame end, and the supported range still includes those
+ * versions: measured on a real 56-line transcript, Node returned 158 bytes /
+ * 1 line where the CLI returned 43,747 bytes / 56 lines. That is a silent truncation to the session header —
  * every call would have reported "no answer yet" forever. `decodeZstdFrames()`
  * below walks the frame headers itself and decompresses each frame, and
  * `test/deepseek-transcript.test.ts` pins it against multi-frame fixtures.