v0.25.0

A Java client can now call a VGI worker.

Everything needed was already published — VgiService declares the full 65-method wire surface, the protocol records serialise both directions, and RpcConnection.proxy drives unary and streaming methods alike. Nothing had ever assembled them: VgiService.class appeared only in new RpcServer(VgiService.class, impl), so the client half of the protocol was correct-by-symmetry and unexercised.

Worker.rpcServer() (new public API) returns the configured RpcServer so a worker can be served over a transport the caller owns. The run* entry points each own their transport and block, so there was no way to pair a worker with a client in one process. Opaque-data sealing is off, matching runStdio / runUnixSocket.

VgiClientRoundTripTest walks the whole scan path a query engine performs — attach → discovery → bind → init → drain — against an in-process worker over a pipe, asserting on decoded rows. It encodes bind arguments in DuckDB's own shape (an args struct of positional_N / named_<name>), covers multi-batch drains, and reuses one connection across several scans. It is the reference for embedding VGI in a JVM consumer.

Assembling it surfaced two bugs in the client path of vgi-rpc-java, fixed in 0.21.4 and pinned here: a @StreamHeader stream delivered its header as the first data batch, and close() hung once the producer reached EOS. Both sit on the path init takes, so the first real client hit them immediately.

Worker-side behaviour is unchanged.