26.11.1.post4: scope, gates and schedule #401

This is the plan and the gates for 26.11.1.post4, the release of all the glue work that follows 26.11.1.post3. The scope is all glue, not only the paths of the benchmark cells: every JSON text that crosses between Java and Python on a bulk or per-row path (#388), and the small per-call overheads that the CRUD audit found. The engine stays byte-identical to 26.11.1, as in post1 to post3.

Candidates, all drafts from the tag 26.11.1.post3, tests first, none of them measured yet: #389 native count(), #390 native create_vertices as a frame, #391 JVM graph_batch typed columns, #392 JVM insert_many typed columns, #393 native async create_record batch, #394 frame kinds for RID and number lists, #395 JVM get_rid readers, #396 JVM new_edge, #397 native reply tail and the dead entry, #398 native approximate vector search by pointer. #390 and #391 come first because the graph loads of the benchmark cells (create_vertices) run through them. I dropped the native columnar head frame (rank 4 of #388): by sizing it saves 0.03 to 0.34 ms per call and needs an API change.

What post3 taught me, and what changes for post4: its timed study had no figure for the exact shape of the benchmark cell that regressed (#400: a single-record UPDATE through command() in a begin and commit pair is about 26 percent slower than on 26.11.1), and it labelled one figure with the wrong auto-transaction mode. So the post4 study has a figure for the operation shape of every benchmark cell that a PR can touch, on both wheels, next to the figures of the PRs, and every figure is checked against the code path that it runs before it is credited to a PR.

Gates, all of them before a tag:

• every candidate that goes in is green on the full CI matrix of its own branch (all legs, both wheels)
• a parity digest per figure: the stored data and the returned values are identical between the arms
• a pre-registered timed A/B per candidate against the released post3 wheel (ABBA, A/A control, latency and peak memory), and the figures of the benchmark cells as a regression guard; a candidate with a figure that is slower than post3 stays out
• the integration branch from the tag with the candidates that passed, its CI-built wheels measured as a whole (the gate run, as for post3)
• the engine identity guard on the CI-built and on the published wheels
• Native: single-record UPDATE through command() is about 26 percent slower on post3 than on 26.11.1 in the l1tpc paper cells #400 is understood, and fixed in post4 or named as open in the release notes
• the docs describe what the tag contains and only the figures that were measured

Resources: CI is the authority for the full matrix. The laptop timed lane runs the A/B studies. The mini builds and tests the branches with Docker while it is idle (the first Java compile does not wait for the shared runner pool) and runs the benchmark cells solo. More timed lanes on the laptop and the mini come after their qualification (tracked in the control plane).

Schedule (estimates, not promises): first compile and test fixes of the candidates on 2026-11-15 and 16; the A/B studies on 2026-11-16 to 18; go or no-go on 2026-11-19; the tag on 2026-11-19 or 20; the mini reruns of the affected benchmark cells (graph loads on both wheels, about 8 hours) on 2026-11-20 and 21; landing on the page and in the paper notes on 2026-11-22 and 23; the paper deadline is 2026-11-24. A candidate that is not ready on the 19th goes into a later release.

Related: #315, #388, #400.