fix(streamingUnzip): avoid detection of incorrect ZIP signature

[cyfung1031]

(Although the code is generated by AI but since 101arrowz do not like AI paragraphs so I write the following)

• Close Issue with extracting a specific zip file using fflate. #243

This is to solve the current design limit of streaming Unzip - causing issue #243.

When it scan the ZIP signatures like 0x8074B50, 0x4034B50, 0x2014B50, etc, it will believe this is end of file.

but this is incorrect since the compressed file might also contain such bytes by chance.

now the field "b" is added to represent "compressed bytes flushed so far for the current data-descriptor entry"

Then using this.b + candidateEndOffset to check whether the compression data matches descriptor, rather than just trusting the ZIP signature bytes.

( A real boundary is always preceded by a data descriptor whose csize field must equal the bytes consumed so far. )

btw z = oc == -2 && 8 is for zip64 data descriptors detection. So that it can check with the 64-bit size as well.

---

if you still don't like AI coding, just take it as a reference and do it yourself.
The coding isn't changed too much and you can read.

---

In addition

• Close Unzipping a file containing a .pptx using Unzip + UnzipInflate #235
• Close Unexpected EOF when inflating ZIP #208
• Suppress Enhance data descriptor handling by adding length check #233

[cyfung1031]

• This also close Unzipping a file containing a .pptx using Unzip + UnzipInflate #235

because #235 is due to the streaming Unzip mixed up the ZIP signatures of the stored zip files and the one it is working on.

[cyfung1031]

• This also close Unexpected EOF when inflating ZIP #208

because #208 is due to the wrong detection of EOL due to the ZIP signature detection