bindings: what the 26.10.1 sync owes (one-way edge refusal #8625, the one-way query contract, warm_up() for #8852) #87

The upstream sync of 2026-10-02 (ce1aa29ebe, engine 26.10.1-SNAPSHOT 802233cb57) brings three engine changes the bindings have not caught up with.

1. Silent empty results over edges without incoming pointers: GraphBatch ignores the edge type's direction, and SQL MATCH reverses a unidirectional type ArcadeData/arcadedb#8625, fixed in fix(#8625): queries answer the incoming side of unidirectional edge types; GraphBatch follows the type's direction ArcadeData/arcadedb#8628: graph_batch(bidirectional=False) on an edge type declared two-way is now refused (new_edge raises naming the type) instead of silently writing half the edge. docs/guide/graphs.md, docs/api/graph_batch.md, and the graph_batch() docstring still say "the batch does not check". No test covers the refusal.

2. The query contract of a UNIDIRECTIONAL edge type (fix(#8625): queries answer the incoming side of unidirectional edge types; GraphBatch follows the type's direction ArcadeData/arcadedb#8628): patterns (Cypher, SQL MATCH) see every edge whichever way they are written; in(), inE(), both(), bothE(), and the vertex API read only what the target stores, which is nothing. Undocumented in the bindings and untested.

3. LSM_VECTOR: the first search after a reopen re-reads every vector's document on one thread (2.8 s at 1M, 17.9 s at 10M; the next search takes 5 ms), and there is no way to pay it at startup ArcadeData/arcadedb#8852, fixed in perf(vector): first search after reopen loads the graph via the ordinal map (#8852) ArcadeData/arcadedb#8863: LSMVectorIndex.warmUp() loads the persisted graph at startup rather than on the first search. Not exposed in VectorIndex, not documented beside the throwaway-search alternative.