jvm: feasibility and binding plan for Java/Kotlin hosts

[Fieldnote-Echo]

Summary

Research and plan a JVM binding surface for Java/Kotlin/Scala hosts.

This is an ecosystem compatibility issue, especially for JVM search stacks. The goal is not to build a vector database adapter; it is to make ordvec's primitive scoring and persisted-index loading available to JVM hosts that own storage, filtering, sharding, and query planning.

Proposed scope

Design an ordvec-jvm approach over either the C ABI or direct JNI/JNA. Initial surface should be read-only:

• load/probe persisted indexes
• index info
• full search
• subset rerank once api: batched RankQuant subset rerank for host-owned candidate sets #115/ffi: batched subset/docset search C ABI surface #137 exist
• explicit close() / native resource lifecycle
• direct-buffer or primitive-array input options
• status-to-exception mapping
• Maven/Gradle packaging plan

Acceptance criteria

• Feasibility doc compares C ABI, JNI, JNA, and Panama-style options where relevant.
• Java smoke test loads a persisted fixture and matches Rust conformance results once implemented.
• Native resource lifecycle is deterministic.
• Packaging plan states supported platforms and native library loading strategy.
• Docs explicitly leave metadata, filters, and database semantics to the host JVM system.

Non-goals

• No Lucene/Elastic plugin.
• No search server.
• No metadata/payload integration.