refactor(ci): extract shared benchmark-job setup into composite action / workflow_call

Context

Surfaced during review of #354. Both .github/workflows/ci.yml (11 jobs) and .github/workflows/ci-results-repo.yml (11 jobs) duplicate the same setup boilerplate across each tool's job: actions/checkout, actions/setup-node, npm ci, npm run build, Run benchmark, fetch gh-pages step (in ci.yml), Store benchmark result invocation, validate command. The two files differ only by:

• gh-repository input on the action (results-repo case)
• Validate-script third arg (./benchmark-data-repository)
• Token used (default GITHUB_TOKEN vs BENCHMARK_ACTION_BOT_TOKEN)

22 jobs share ~80% of their YAML.

Problem

• Any change (e.g. node version bump, action input, validate command shape) must be replicated 11–22 times.
• #354 itself touched this duplication (drop Save previous data.js × 22, plus add fetch step × 11). Future similar changes will keep paying the same tax.

Proposal

Two paths, pick one:

1. Composite action at .github/actions/setup-bench/action.yml — wraps actions/checkout, setup-node, npm ci, npm run build. Each job calls uses: ./.github/actions/setup-bench then runs its tool-specific Run benchmark step plus Store benchmark result.
2. workflow_call reusable workflow with matrix over (tool, target_repo). Single source of truth; a tool value selects which benchmark-runner step to use; target_repo selects gh-repository / token / validate-arg.

(2) collapses both YAML files into one. Bigger refactor but eliminates the file split entirely.

Out of scope

• The actual race fix in #354 (already done).
• Anything that changes runtime semantics — refactor must be behavior-preserving.

Acceptance

• ci.yml + ci-results-repo.yml shrink ~70%.
• Adding a new benchmark tool requires ≤1 job entry, not ≥2.
• All existing 22 jobs continue to pass.

Inizia confrontando .github/workflows/ci.yml e .github/workflows/ci-results-repo.yml, concentrandoti sui passaggi duplicati di setup, benchmark, result-storage e validation. Valuta le proposte composite-action e workflow_call rispetto ai loro diversi input per repository, token e validazione. Il lavoro è completato quando i workflow sono sostanzialmente più piccoli, un nuovo strumento richiede al massimo una voce di job e tutti i 22 job esistenti continuano a superare i test senza modifiche a runtime.