Vertex.new_edge on a vertex object read earlier raises ConcurrentModificationException on the JVM build only #215

On the JVM build, Vertex.new_edge raises ConcurrentModificationException when the vertex object was read before the first edge of that vertex was committed. The native build succeeds in the same program.

Repro (single thread, no concurrency): load the vertices once with db.lookup_by_rid(), then for each operation run with db.transaction(): vs[i].new_edge("E", vs[j]). The first edge of a vertex rewrites the vertex record (the head chunk of its edge list). The cached ImmutableVertex in Vertex._java_document still holds the old version, so the next newEdge from it fails at update with Record #3:4 was modified by a concurrent transaction between its read and its update. The record was modified by the program's own earlier commit.

Cause: the JVM wrapper calls self._java_document.newEdge(label, target_java, ...) on the object as read, and passes the target as a Java vertex object, which is stale in the same way. The native wrapper sends both record ids to CREATE EDGE FROM :src TO :dst, so the engine loads the current records.

Fix: resolve the source by record id inside the active transaction (one lookupByRID) and pass the target as its record id, so the engine loads it. Both builds then accept any vertex object, which is what the native build and the new_edge docstring already promised. A regression test runs on both builds.

Found by the bindings discovery pass of 2026-11-03 (case new_edge).