[COMPRESS-643] Reset ZIP entry counts after draining previous entries - #838

Advancing to the next ZIP entry closes the previous entry implicitly. For a DEFLATED entry with a data descriptor, that close can drain unread data through read(). The counter was reset before this drain, so the next entry inherited the previous entry's unread-byte count. A 100000-byte unread entry left the next entry starting at 100000 instead of zero.

Reset the uncompressed count after closing the previous entry, while preserving a zero count when advancing a closed or exhausted stream. Add seven in-memory regression/control cases covering unread, one-byte, fully consumed and STORED entries, partial final-entry reads, and closed streams. This fixes the skipped-entry counter problem in COMPRESS-643; it does not require a partial-read compression ratio to equal the whole-entry ratio.

Validation on JDK 21 with the project's Java 8 compiler configuration:

• Original production code: 67 ZIP tests, three expected assertion failures in the new regressions, zero errors.

• Patched production code: all 67 ZIP tests pass.

• Default mvn -B -ntp: BUILD SUCCESS; Surefire reports 4788 tests, zero failures/errors, 29 pre-existing skipped tests (4759 passed). No additional skips or test exclusions were added.

• A separate six-case in-memory reproduction also passes against the patched classes.

• Read the contribution guidelines.

• Read the ASF Generative Tooling Guidance.

• AI was used: DeepSeek assisted with diagnosis, test and fix generation, and first-pass review. Codex coordinated the work, corrected and reviewed the patch, independently ran the native validation, and prepared this description. The commit includes Assisted-By trailers. No human review is claimed.

• Run a successful build using the default Maven goal.

• Add behavioral tests that fail against the original production code.

• Describe the problem, resulting behavior, and validation.

• Use a meaningful commit message containing the existing Jira key.