CI: 'Pre-publish benchmark gate' 1-file rebuild check is chronically flaky at the 75% threshold, unrelated to PR content

[carlos-alm]

The `Pre-publish benchmark gate` job's `1-file rebuild` regression check has been failing intermittently, by a razor-thin margin right around its 75% threshold, across many unrelated PRs recently (observed today on PR #2021, and per prior session notes also on #1992, #1998, #2000, #2002, #2012, #2013, #2014, #2018 — none of which touch anything plausibly connected to file-rebuild performance).

Example from PR #2021 (fix(native): thread config.db.busyTimeoutMs into NativeDatabase open factories — a PR with zero plausible connection to WASM rebuild timing):

• Run 1: 1-file rebuild: 112 → 202 (+80%, threshold 75%) and 113 → 198 (+75%, threshold 75%)
• Run 2 (rerun): 1-file rebuild: 112 → 201 (+79%, threshold 75%) and 113 → 205 (+81%, threshold 75%)

The baseline (~112-117ms) and measured (~198-209ms) values are both very small in absolute terms, so a few ms of CI-runner scheduling noise translates into large percentage swings right at the threshold boundary.

This is the same class of problem previously investigated and closed in #1855 ("perf: 1-file incremental rebuild regresses +79-81% (117ms -> ~209ms)"), #1864 ("CI: '1-file rebuild' benchmark baseline (117ms) appears stale against current runner performance"), and #1440 ("benchmark.ts incremental tiers lack warmup runs — CI jitter shows as 1-file rebuild regressions") — but it keeps recurring, suggesting those fixes didn't durably resolve the underlying measurement noise.

Suggested directions (not scoped/investigated here):

• Add proper warmup iterations before the timed 1-file-rebuild measurement (if benchmark.ts incremental tiers lack warmup runs — CI jitter shows as 1-file rebuild regressions #1440's fix didn't fully cover this path).
• Widen the 1-file-rebuild threshold specifically (it appears disproportionately noisy vs. the other benchmark tiers) or switch it to a median-of-N-runs comparison.
• Consider skipping/relaxing this specific check on shared/variable-performance CI runners.

Filed per this repo's scope-discipline convention while triaging PRs #2021/#2022/#2024 — out of scope for those PRs' own content, but a real recurring CI reliability gap that shouldn't go untracked.

[carlos-alm]

Update: this same chronic flakiness also affects the "Full build" regression metric in the same benchmark gate (not just "1-file rebuild" as originally titled) — observed at a consistent +31-35% (threshold 25%) across PRs #2024, #2026, and #2028, all with unrelated code changes. Same root phenomenon: a CI-runner-performance-vs-stored-baseline mismatch, just manifesting on a second benchmark tier. Widening the scope of this issue's suggested fix (baseline refresh / warmup / threshold review) to cover both tiers.

[carlos-alm]

Another occurrence on PR #2104 (fix(perf): resolve config once in withRepo to avoid double loadConfig — a small 4-file config-resolution change with no connection to build/rebuild performance):

• Run 1: 1-file rebuild: 117 → 182 (+56%, threshold 50%) (native), 112 → 208 (+86%, threshold 75%) (wasm), Full build: 3521 → 5178 (+47%, threshold 25%) + 1-file rebuild: 117 → 183 (+56%) (native incremental), 1-file rebuild: 113 → 210 (+86%) (wasm incremental)
• Rerun: same 4 assertions failed again, similar magnitude

Also confirmed this is currently failing on essentially every recent PR run in the repo (checked ~7 other unrelated in-flight PRs from the last day — all show Pre-publish benchmark gate failing). This continues to look like a CI-runner-performance-vs-stored-baseline mismatch rather than a real per-PR regression, consistent with the rest of this issue's history.