….3.1 (#145)

Fixes the Node 26 CI failure on master, and moves both zip dependencies
to their upstream, maintained versions.

## yauzl: the Node 26 fix

`@eggjs/yauzl` depends on `fd-slicer2`, whose `ReadStream` loses data
when piped on Node 26. Any zip entry over the 64 KiB `highWaterMark`
delivers roughly the first chunk and then stalls, with no `end`, no
`error`, no `close`. That is why `zip.uncompress()` hangs until the 60s
timeout on Node 26 while passing on 18 through 24.

Not our code: released 2.1.1 reproduces it identically. Reported
upstream at node-modules/yauzl#3.

`yauzl@3.4.0` dropped `fd-slicer` entirely (only dependency is now
`pend`) and does not have the bug.

The fork was adopted for `decodeStrings: false` so absolute paths
survive `validateFileName`. I checked that still holds against the
`contain-absolute-path.zip` fixture rather than assuming:

| | @eggjs/yauzl 2.11.0 | upstream 3.4.0 |
| --- | --- | --- |
| entries | 31 | 31 |
| `fileName` is Buffer | 31 | 31 |
| `externalFileAttributes` present | 31 | 31 |
| files read | 21 | 21 |
| leading `/` entry | preserved | preserved |

Only visible difference: yauzl 3 capitalises the "End of central
directory record signature not found" message, so that assertion is now
case-insensitive.

## yazl 3 and the early-finalize bug it exposed

yazl 3 turns "add entries after calling `end()`" from a tolerated no-op
into a thrown error, and compressing trips it immediately.

`_onEntryFinish()` finalizes as soon as the entry queue is momentarily
empty. For zip the finish callback runs synchronously, so a caller
doing:

```js
zipStream.addEntry(streamA, ...);
zipStream.addEntry(bufferB, ...);
```

closed the archive after the first entry, and the second threw. Tar
avoids it only because its `fs.stat` makes the callback async, which
lets the later entries queue first.

Worth being precise about the old behaviour: **yazl 2 did not drop those
entries.** I checked, and the produced archive contained all of them. So
this was latent, not a live data-loss bug.

Fix is to finalize on the next tick and skip it if an entry arrived
meanwhile. Verified the produced archive still contains every entry.

Residual limitation, unchanged in spirit from before: entries added
after a longer async gap still finalize early. That is the existing
drain heuristic, and giving the stream an explicit "done adding" call
would be an API change worth doing separately.

## Result

**171 passing on both Node 24 and Node 26**, lint and `tsc` clean. On
Node 26 the zip suite finishes in ~495ms where it previously hung for
60s. The symlink cases from #140 were re-checked through the new zip
path and still block.

Drops `fd-slicer2` and `buffer-crc32` from the tree. Supersedes #132.