LZWDecode content stream decodes one byte short with no error

Environment

pdfcpu v0.15.0, go1.26.1 darwin/arm64, macOS 26.6.2.

What happened

A page content stream compressed with LZWDecode decodes one byte short, with no error reported. The attached PDF has a single page whose content stream decodes to 3842 bytes.

$ pdfcpu extract -m content repro.pdf out
$ wc -c out/repro_Content_page_1.txt
3841

The last 8 bytes come out as " \n%BT\x00\x00" where they should be " \n%BTBTB" — two zero bytes in place of three real ones.

Expected

3842 bytes. poppler (pdftotext/pdfinfo) reads the same file and decodes the stream correctly, so I don't think the file is malformed.

Notes on the reproducer

The PDF is synthetic. I built it because I hit this on scanned TIFFs from a PDF writer whose LZW output fills the dictionary, and I couldn't get any ordinary encoder to produce the same stream — libtiff and compress/lzw both send a clear code when the table fills, which avoids the case entirely. So the attached file's code stream is hand-built. The content operators are real though, which is why poppler renders text from it.

The trigger is the dictionary filling and the next code being 4095.

The same code shape exists in golang.org/x/image/tiff/lzw and is being tracked at golang/go#81125, in case that's useful context.

repro.pdf