ci: nightly day-over-day performance regression gate - #1626

Add a self-contained perf-regression job to the nightly that runs a
redis-benchmark suite against the freshly built module and compares
throughput (ops/sec) against the previous nightly's baseline artifact.

- A metric >5% slower than the baseline fails the nightly (turns it red).
- The baseline is a ratchet: it only moves in the faster direction
  automatically. On a regression the old (faster) baseline is kept so the
  bar does not erode silently.
- To deliberately accept a slower baseline ("lower the bar"), re-run the
  nightly via workflow_dispatch with approve-lower-baseline=true.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RabQEggYzz3s3JJ16ZUJ3i

Replaces the runner-based benchmark from the previous commit. GitHub runners are not a
trustworthy source of performance signal, and the EC2 perf suite already pushes every result
to RedisTimeSeries, so the gate now reads those series back instead of measuring anything
itself.

perf_regression_gate.py queries the same labels redisbench-admin's own `compare` uses
(branch / metric / test_name / deployment_name / triggering_env / github_org / github_repo)
and judges the newest results against a ratcheted baseline:

- The baseline is the best trailing-window median in the query window, so it only ever moves
  in the faster direction -- a slow run cannot lower it and performance cannot erode silently.
- Ratcheting on a median-of-N rather than on single runs is what makes that usable: EC2
  variance is large, and a max over individual samples would latch onto an outlier and then
  fail forever.
- The threshold widens to the noise floor measured for each test; past --max-threshold-pct
  observed noise a test is reported as not gateable rather than flapping.
- An empty result set is a hard failure. `compare` itself never fails a build, and a gate that
  silently matches no series must not be mistaken for one that passed.

Lowering the bar is a reviewed change to tests/benchmarks/perf-baselines.json, recording the
value, who approved it and why -- nothing the gate does can lower it on its own.

Wired after each merge to master (attributing a regression to its commit) and nightly as a
safety net. Both start with enforce: false so the thresholds can be calibrated against real
EC2 variance before the gate turns anything red.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>