[dgant]

Reduce work before the first BWAPI connection attempt: connect before creating frame buffers, metrics, and the bot wrapper, and bind only the Windows mapping functions the client uses.

mvn package also produces one distribution ZIP containing the existing JAR and architecture-named Windows DLLs directly beside it. The DLLs come from the finished JAR, so the packaged versions match. Licenses stay inside the JAR. No native-path flags or directory setup are needed.

The loader selects the running JVM's architecture and verifies the adjacent DLL against the embedded copy. Missing or stale DLLs fall back to a private, verified cache; unavailable caches fall back to ordinary JNA extraction. Explicit JNA loading settings take precedence. JAR-only deployments and other supported platforms continue to work.

The packaging change uses one Maven ZIP task and removes the separate assembly descriptor. The test heap is 768 MB to support Java 8 x86. Connection retry behavior is unchanged.

Validation:

• Final packaging and loading changes: Java 8 x86 Maven package passed; 14 focused startup, mapping, and native-loading tests passed on x86 and x64, with two platform-specific skips on each.
• PurpleWave Maven package passed on Java 8 x86. Its finished ZIP loaded the correct adjacent DLL on x86 and x64 with extraction disabled, from an unrelated working directory; JAR-only cache fallback also passed on both.
• All three tournament-packaging tests passed. Inspected the real Maven, AIIDE, BASIL, SSCAIT, and SCHNAIL ZIPs: DLLs match the JAR byte-for-byte, licenses are inside the JAR, and no nested native directory remains.
• Earlier validation of the startup/cache implementation included the full Java 8 suite on Windows x86/x64 and Linux x64, and five complete PurpleWave games under Java 8 x86/Wine without crashes, timeouts, or logged bot errors. Those games preceded the later packaging and readability cleanup.
• ARM64 DLLs are packaged from JNA but have not been executed on ARM hardware.

Full PurpleWave startup measured from process launch to first BWAPI lookup improved from a 475.1 ms median to 119.1 ms (five samples per version, Java 8 x86, warm filesystem caches). This is a measurement on one machine, not a startup guarantee.