Cache converted resource packs by effective stack and ZIP hash

[AlexProgrammerDE]

Description

Fixes #416. Supersedes #417.

Bedrock announces pack identities in RESOURCE_PACKS_INFO, then sends the effective pack order in RESOURCE_PACK_STACK. The Java pack is now pushed only after the stack arrives and the Bedrock sources have loaded. Conversion uses that stack order, so pack overrides match the server's choice.

The HTTP server prepares the converted ZIP before the Java push. The push advertises the SHA-1 of the exact ZIP it serves and a stable UUID derived from that SHA-1. A new URL token still restricts each connection's download, while an unchanged ZIP keeps the same hash and UUID for the Java client's cache.

Source pack caches use the advertised content ID and decryption key in addition to pack UUID and version. If Bedrock provides no content ID, the source is downloaded again rather than trusted by UUID and version alone. The converted cache keys on the ordered source bytes and ViaBedrock build version. Disk entries are checked against their SHA-1 before reuse; pack-cache disabled, memory, and disk modes apply to converted packs as well.

ZIP entries are written in a stable path order. Stack-only packs cannot replace sources already loaded from the Info packet.

Testing

• ./gradlew build
• Regression tests cover pack order, changed source bytes, source content identity, and stable ZIP bytes, SHA-1, and UUID.

Live Bedrock server and Java client behavior still needs verification. A Bedrock server that changes pack bytes while reusing a nonempty content ID can still make its own source cache stale, because the advertised metadata gives no way to detect that change without downloading it.