Add backend regression benchmark harness

[Byron]

Add a backend regression benchmark harness that compares the current checkout against a known-good pre-#502 commit on the same runner.

This is intended as a regression guard for backend-sensitive performance paths, not as a fix for the underlying slowdown. The benchmark should reproduce the issue on main, establish a baseline from before the regression, and fail when the current code exceeds the allowed slowdown derived from measurement uncertainty.

Tasks

• wait for the official fix from @folkertdev (needs additions to the public api of zlib-rs)
• review the benchmark harness or drop it if it's too messy (we can also just hope for this to not happen again)

How it works

This adds an ignored integration test, tests/backend-regression-bench.rs, that:

• benchmarks a small set of backend-sensitive compress/decompress cases in release mode
• creates a detached worktree at KNOWN_GOOD_COMMIT
• generates a temporary Cargo project whose manifest points flate2 at that known-good worktree
• copies tests/support/backend-regression-driver.rs into that temporary project and runs it to collect baseline measurements
• compares the current run against the baseline and fails if the observed slowdown exceeds the combined uncertainty of the current and baseline measurements
• writes CSV artifacts to target/backend-bench/*.csv

The baseline driver is kept as a normal Rust source file instead of an embedded string so the setup remains easy to reuse and reason about across historical and current revisions.

CI

This also wires the backend regression benchmark into CI via a dedicated workflow:

• .github/workflows/backend-regression.yml

That workflow now runs on:

• push
• pull_request
• workflow_dispatch
• nightly schedule

Each matrix job runs the ignored benchmark in release mode for one backend and uploads the generated CSV artifacts.

How to use

Run the default backend locally with:

cargo test --release --test backend-regression-bench -- --ignored --exact backend_regression_bench --nocapture

Run another backend, for example zlib-rs, with:

cargo test --release --test backend-regression-bench --features zlib-rs --no-default-features -- --ignored --exact backend_regression_bench --nocapture

Inspect artifacts after a run in:

target/backend-bench/*.csv

Maintenance

This is meant to be maintained as a long-term regression check:

• update KNOWN_GOOD_COMMIT only when intentionally accepting a new performance baseline
• keep the temporary baseline driver reusable and branch-independent
• extend the benchmark cases if other low-level performance-sensitive APIs should also be covered

Related

• Related issue: Performance regression in zlib-rs backend, more zeroing of memory than before #544
• Related issue comment: Performance regression in zlib-rs backend, more zeroing of memory than before #544 (comment)
• Baseline reference point: PR Add (de)compress_uninit that accepts &[MaybeUninit<u8>] #502
• Success criteria from the issue discussion: reproduce the regression on current main, compare against the pre-Add (de)compress_uninit that accepts &[MaybeUninit<u8>] #502 baseline, and check that in CI