FullPacketParser: emit partialReadError with the chunk it could not read

[u9g]

FullPacketParser._transform drops a chunk it cannot read and moves on, which is the right behaviour for a stream of whole packets. But it discards the chunk on the way: the only trace is console.log(e.stack), and even that goes away under noErrorLogging. A consumer cannot find out which bytes failed to parse.

That matters when a server's registry disagrees with the client's definitions. A 1.21.3 server sending particle id 47 (item_slime, no payload) to a 1.21.4 client, whose definitions read 47 as trail (a vec3f64 and more), throws PartialReadError on every particle packet. One bot logged 14,814 stacks, none of them carrying the packet.

This attaches the chunk to the error as error.buffer and emits it as 'partialReadError' before the existing log, so a consumer can record the bytes, diff them against the schema, or count them. The event is not 'error': emitting that on a Transform ends the stream, which is exactly what the drop-and-continue path exists to avoid.

Nothing else changes. The log line and the drop are as before, and noErrorLogging still controls only the log. Parser is untouched: a partial read there means the rest of the packet has not arrived yet, not that the bytes are wrong.

The plain Parser already sets e.buffer on the errors it forwards, so the field name follows it.

Typed in index.d.ts and documented in doc/api.md, which had no FullPacketParser section. Test covers the interpreted and compiled parsers: the event fires once with the chunk, and the next packet still parses.