make_2610_stages: --order tiers queues ArcadeDB first, existing comparators second, new versions and new arms last - #222

…de the JVM server, four ArcadeDB arms from one engine commit

DECISIONS #222 (user, 2026-10-30): the page and the paper show ArcadeDB's native and JVM builds side by side in embedded AND server mode.
Upstream publishes an official native-image server (arcadedata/arcadedb:<version>-native, native-image.yml, native/pom.xml), so the native server
arm is that image, addressed exactly like the Docker JVM server: no launcher, same client, cpuset, memory cap and split.

1. runner: a chain whose wheel is the native build runs every served ArcadeDB arm on ARCADEDB_NATIVE_SERVER_IMAGE (refused when unset: F5, wheel +
   JVM image + native image are one commit). native_server_arm derives the container command (the scratch image has no shell and no JAVA_OPTS: its
   entrypoint takes -D<setting> and -Xmx arguments) FROM the JVM arm's own JAVA_OPTS, so both servers are configured from one list; -XX flags have no
   native meaning and are recorded in native_dropped_flags. The image-defaults sensitivity arm and e4 have no native counterpart and stay in the JVM chain.
2. Explicit settings for both servers: the JVM image left server mode, bind host, port and (relaxed class) txWalFlush to its defaults; they are now
   written out for every served arm, and the strict class replaces the txWalFlush token (one token: the JVM takes the last, the native image the first).
   Left at the engine default on both and only read back: arcadedb.maxPageRAM. arcadedb_settings_readback asks each running engine over HTTP
   (server?mode=default, schema:database, SELECT version()), stamps server_settings / server_engine_commit on the row and refuses a cell whose engine
   runs a requested setting otherwise or whose commit is not the pin. observe_server reads -Xmx and the -D tokens from the container's Cmd too.
3. Rows: server rows carry engine_backend native|jvm (old server rows without it are the JVM server); the client container reports the build of the
   server it talks to (BENCH_ARCADEDB_SERVER_BUILD), the runner stamps killed cells from server_build. arm_identity.built() = in-process or served;
   labels "ArcadeDB (server, native build)" / "(server, JVM build)"; the build-pair gates, not-measured declarations and per-build notes apply to
   server arms through the same code. pair_problems also compares server settings between the builds of one cell and the servers' engine commit.
   cpu_baseline is stamped per artifact (native server -march=x86-64-v3 from native.march, native wheel -march=compatibility, JVM at run time) and
   disclosed under the server tables from the rows; neither baseline is changed.
4. Stage generator: the native chain no longer skips served arms; it exports the native image pin and BENCH_SERVER_BUILD (the runner refuses a value
   that is not its wheel's build) and checks the native server's commit in the pre-flight (verify_native_server_image.sh). chain_served_problems:
   each chain runs the served arms of its own build once, the same ones in both; the lint refuses a script that names the other build's server.
   Output of the JVM chain and of old-wheel chains is byte for byte unchanged (stage_drafts_2611.sha256 holds).
5. make_paper_tables: no single-build default (the sparse path takes a build or "all"; the T2 and sparse tables print both builds).
6. smoke_native_server.sh (not run here): one served cell of l2 and one of docs_oltp on the published native image, rows checked; PAGE-SPEC and
   READING-RESULTS describe the four arms and the CPU baseline disclosure.

Tests: test_native_server_arm.py (new, 15), test_chain_served_arms.py rewritten, test_build_pair_page.py and test_native_jvm_arms.py updated for server
rows carrying a build; on the pre-change code 25 tests fail and the 10 page-fixture tests error. Full benchmarks/experiments suite: 1131 passed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>