[FEA] Lucene: provide a thin-JAR adapter for configured PyLucene HNSW

Problem

Stock PyLucene wraps Lucene APIs but cannot directly construct cuvs-lucene's parameterized Lucene101AcceleratedHNSWCodec. Compiling a Java adapter at cuVS Bench runtime would put Java source under Python ownership and add an avoidable compiler prerequisite.

Proposed change

Add a small production adapter to the standard thin cuvs-lucene JAR. Its public no-argument constructor should read namespaced JVM properties for Lucene maxConn and beamWidth, validate them, snapshot them into AcceleratedHNSWParams, and delegate to the existing codec.

The adapter must be loaded explicitly by class name and must not be registered as a Lucene SPI provider, because SPI instances are cached and required properties would make enumeration unsafe. Add property-validation, repeated-construction, codec-name, thin-JAR-content, and fresh-JVM PyLucene coverage.

This is an additive API; existing codecs and persisted names remain unchanged. Related to #2470 and #2194.

Start with Lucene101AcceleratedHNSWCodec and AcceleratedHNSWParams, then inspect how the standard thin cuvs-lucene JAR is built and how PyLucene loads Java classes. Add the explicitly named adapter and cover property validation, repeated construction, codec naming, thin-JAR contents, and fresh-JVM PyLucene behavior; done means existing codecs and persisted names remain unchanged and the adapter is not an SPI provider.