Vector vertex loads: the JVM wheel spends about 60 percent of the wall in unwrapped Python when rows hold Java float[], the native wheel about 30 percent in prep #337

From the untimed ingest profile of the released 26.11.1 wheels (no speed claim; 3 repetitions, 66 cells, none void): a create_vertices load whose rows hold Java float[] vectors (the shape the e2 and l3d lanes use) spends 59.2 percent (e2) and 60.6 percent (l3d) of the JVM wheel's measured wall in Python code that no phase counter covers, and the native wheel spends 31.3 percent (e2) and 29.0 percent (l3d) in its prep phase (the vector split and the binary argument encoding).

Read in the profile: the JVM cells count only createVertices (the property-matrix call of the engine's GraphBatch) and no batcher call, so a load with Java float[] rows takes the property-matrix path, and _create_vertices_json_bulk returns None at the first Java float[] (graph_batch.py), so the scan costs one row, not every row. A Java float[] is not a vector candidate, and the 60 percent is in _to_java_property_matrix (a Python loop over each row's properties, one JArray(JObject) per row, the whole input held at once), read from the code, not timed. A numpy array or a list of floats is documented to take the binary-matrix path instead.

Proposal: recognise a Java float[] (and a numpy float32 array) as a vector candidate on both wheels and send it through the one binary-matrix path, with a test that the stored vectors are bit-identical to the old path; measure per-phase time and memory (B per row) before and after. This is not gated on a paper cell: every glue drawback found gets fixed.

Edited: the first version said the scan reads every row; PR #339 read the code and it stops at the first Java float[].