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.