post4: confirm each candidate solo on the mini against 26.11.1, post2 and post3, then cherry-pick only what passes #405

Part of #401 (the plan and gates of 26.11.1.post4).

The timed A/Bs of #401 measure each candidate against the released post3 wheel on the laptop's E cores. The paper's numbers come from the mini's P cores, solo, and #404 showed that the speed of a native build depends on the build draw and on the host. Before anything goes to main and into the tag, I want one reading on the paper's host that puts every wheel side by side, so that what to keep is decided on the hardware that produces the published numbers and not only on the laptop.

Plan

1. One multi-arm study on the mini's solo pair, ABBA with an A/A arm, in the style of the build-spread study (eight arms in one round worked there). Arms: 26.11.1, post2 and post3 as published (post1 is not an arm: its native wheel was never published to PyPI, only its JVM wheel was, so it is not a release of both packages), the post4 integration wheels (the branch of 26.11.1.post4: scope, gates and schedule #401 with the candidates that passed, CI-built), and a sibling CI build of one wheel where the build draw could confound the reading. Figures: the operation shapes of the benchmark cells and the figures of the candidates, as in the laptop study; latency per operation, and peak and anonymous memory as information.
2. The reading rules are written before the run and are those of sections 3 and 4 of the laptop study's README, unchanged (the A/A band, the clean pairs, the verdict names, no claim from a WEAK, INVALID or ERR figure). Two additions, written here before any run: a figure that moves between two builds of the same commit by more than the build spread of Native wheels of one commit differ in speed: the published 26.11.1.post3 runs the single-record UPDATE about 32 percent slower than the CI build of the same commit #404 is read as a build draw and not credited to a candidate; memory is information, but a rise beyond its interval is named in the result.
3. The cherry-pick: only candidates that pass on both hosts go into the integration branch that main receives and into the tag. A candidate that passes on the laptop and fails on the mini stays out of post4 and goes to a later release; an exclusion costs one CI rebuild of the integration wheels.
4. Where it sits: after the laptop A/Bs and the integration build, as part of the gate run of 26.11.1.post4: scope, gates and schedule #401 (the integration wheels measured as a whole), before the go or no-go. The mini's graph-load reruns for the paper (about 8 hours, solo, n=3) follow the tag as planned.
5. The result goes into this issue as one table made by script from the study's score file (arm, figure, ratio against 26.11.1 and against post3 with its interval, verdict, peak memory), with the commit of the scripts and the date.

Done when

• the arms and the figures are listed in the study README before the first timed run
• the study ran on the mini solo pair with an A/A in the band, and the table is in this issue
• each candidate is marked in or out of post4 with the figure that decided it
• the integration branch contains exactly the candidates marked in, and main receives only that

Not here

The paper reruns themselves (graph loads on both wheels) stay in #401, after the tag.