Catching performance regressions on main: compare benchmark runs, and a nightly A/B I can run #10472

Why. #10432 merged on Oct 20 and did what it set out to do: whole-graph reads over a Graph Analytical View with an overlay got about twice as fast (#10411). The same merge made point reads on the view about three times slower while writes are running (#10471: per-query time 2.96x, 95% CI 2.48 to 3.12, 7 of 7 interleaved pairs, against its parent commit). No test failed, because the tests check answers, not speed, and nothing compares the speed of one build with the previous one. I caught it only because I happened to A/B that merge the same night.

What exists today. benchmark-tests.yml runs the *Benchmark classes weekly and load-tests.yml runs daily, both on shared ubuntu-latest runners and with --fail-never. So the numbers are produced but not compared with anything, and shared runners are too noisy to see a change smaller than a large jump.

Proposal, in three small steps.

1. Keep each benchmark run's numbers (an artifact or a results branch) and compare them with the previous run. When a benchmark is slower beyond its usual spread, open an issue instead of failing the build.
2. Add benchmarks for the shapes that have regressed before. The one above is a small program (a view, a reader running point and whole-graph 2-hop counts, a writer committing at a fixed rate); I would contribute it as a *Benchmark class.
3. Measure the merges on a quiet machine. I already run interleaved A/B rounds with a noise model on a dedicated host, and from late November that host re-measures each new ArcadeDB version continuously. I can run a nightly A/B of main against the previous night and file what moves, with the statistics.

Would you take 1 and 2 as pull requests? And which workloads would you want covered first?