Adapt release performance benchmarking workflow from la-stack

[acgetchell]

Context

acgetchell/la-stack#150 landed a release-performance benchmarking workflow that standardizes how maintainers compare current work against prior releases, promote one curated report into committed docs, and archive older release comparisons.

Bring the same operator experience to this repository, adapted to Delaunay's benchmark surface. The command names should match la-stack; the benchmark suites behind those commands should be the Delaunay-appropriate release signal.

Desired command surface

Add or align these commands so they mean the same thing here as in la-stack:

just bench-latest
just bench-latest-vs-last
just bench-compare
just bench-save-baseline <tag>
just bench-save-last
just performance-local
just performance-github-assets
just performance-release

bench-compare should also support comparing against an explicit saved baseline, and performance-release / performance-github-assets should support explicit <current-tag> <baseline-tag> repair paths.

Delaunay-specific benchmark scope

Use the existing benchmark infrastructure where possible. The likely release-signal set should be based on Delaunay's public performance contract rather than every exploratory/profiling benchmark, for example:

• ci_performance_suite for public triangulation workflows and regression signal;
• circumsphere_containment for query performance;
• focused predicate or topology benchmarks where they give release-relevant signal, such as cold_path_predicates or topology_guarantee_construction;
• validation-level benchmarks that explicitly cover Levels 1-5, with component-level timing where useful for TDS structure, topology, embedding, Delaunay property, and cumulative validation;
• math-intensive geometry/topology kernels that materially affect validation or user workflows, especially orientation, barycentric simplex-intersection checks, circumsphere/insphere families, simplex quality/volume/radius helpers, ridge/Euler topology checks, locate/hull traversals, and simplex barycenter queries;
• allocation hot-path checks only where the output is stable enough for release-to-release comparison.

Keep broader profiling runs available, but avoid making the default release comparison too expensive or too noisy.

Acceptance criteria

• The same high-level commands listed above exist here and are documented with the same semantics as la-stack.
• bench-latest runs the repo-specific release-signal benchmark set and leaves Criterion output suitable for comparison.
• bench-latest-vs-last runs latest measurements and renders a Markdown report against the saved last baseline.
• performance-local compares the current tree against the latest stable published release using isolated temporary worktrees.
• performance-github-assets compares stored GitHub Release benchmark assets without local benchmark runs.
• performance-release promotes one curated release-to-release comparison into committed docs, archives the previous committed report under docs/archive/performance/, and supports explicit tag repair.
• Release benchmark assets remain durable GitHub Release artifacts and are compatible with the local comparison tooling.
• Validation benchmark coverage explicitly maps Levels 1-5, including Level 1-2 TDS structure, Level 3 topology, Level 4 embedding, Level 5 Delaunay property, and full cumulative validation.
• Math-intensive benchmark coverage is reviewed and filled where missing for orientation, barycentric simplex-intersection checks, circumsphere/insphere predicates, simplex quality/volume/radius helpers, ridge/Euler topology work, locate/hull traversal, and simplex barycenter queries.
• Existing Delaunay benchmark docs are updated so maintainers know which command to use for release checks, local regression checks, validation-level benchmarks, math-kernel benchmarks, and broader profiling.
• Python/script tests cover report generation, tag-pair resolution, archive safety, and no-baseline/error paths.

Notes

This should preserve Delaunay's existing benchmark-utils machinery where it is already doing the right thing. The goal is command and release-workflow consistency across repos, not a wholesale rewrite.

[acgetchell]

Relationship note: this work supports #408 and #445. The benchmark taxonomy here should provide performance/reproducibility evidence that #445 can summarize in scientific-basis docs and #408 can map into the paper artifact. It is not by itself proof of correctness; keep it distinct from tests, validation contracts, invariant documentation, property tests, and regression tests.