fix(data): enforce decompression limit and reject payload on KMZ directory entries

[dkhawk]

Fixes #1790

Problem

KMZ directory entries (names ending with /) were previously skipped in KmzParser without reading through CountingInputStream. When ZipInputStream.closeEntry() was subsequently called, the underlying runtime implementation silently inflated and discarded any compressed data payload within the directory entry without incrementing the uncompressed byte counter. An attacker could construct an archive containing a directory entry with a large compressed payload (e.g., 512 MiB compressed down to ~500 KB), bypassing the configured maxKmzUncompressedTotalSize (50 MiB default) and causing CPU starvation or ANR dialogs.

Solution

1. Immediate Payload Detection on Directory Entries: Under PKWARE ZIP specifications, directory entries must not carry any data payload. Reading even a single byte from the directory entry detects rogue payloads immediately ((1)$) and throws an IOException without inflating the rest of the stream.
2. Defense-in-Depth Draining: Added drainEntry(countingStream) prior to zipInputStream.closeEntry() to guarantee that any unread bytes in any entry pass through CountingInputStream and count towards maxKmzUncompressedTotalSize.
3. Cleaned up redundant fully qualified exception types.

Testing

• Added regression test parse rejects directory entry with payload exceeding decompression limit in KmzParserTest, reproducing the failure on unpatched code and verifying rejection with the fix.
• Added parse allows legitimate empty directory entries in KmzParserTest verifying standard KMZ archives with directory entries parse cleanly.

[googlemaps-bot]

Code Coverage

Overall Project	51.59%	🍏
Files changed	100%	🍏

Module	Coverage
Kover Gradle Plugin XML report for :data	51%	🍏

Files

Module	File	Coverage
Kover Gradle Plugin XML report for :data	KmzParser.kt	87.85%	🍏

[LoyalAbbas]

LGTM

[kikoso]

LGTM!