fix(test): stabilize Markdown parser perf budgets under parallel load - #3848

…runs (#3860)

Two reliability fixes for the review gate:

1. Stale check-run neutralization. PRs gated before the switch to a commit-status gate still carry an action_required review-required CHECK RUN. Since the gate is now a STATUS, nothing updated those check-runs, and a leftover action_required drags the status rollup to FAILURE even when the status is success — so approved PRs stayed blocked (e.g. #3847). Both the flag job and review-clear now update any stale review-required check-run to neutral once the status is set.

2. Direct fork-safe clearing. review-clear previously re-dispatched the flag job (approve → Review signal completes → workflow_run → dispatch → flag), and any dropped hop left approved fork PRs stuck at pending (e.g. #3848, #3803). It now clears DIRECTLY in the workflow_run context (write-capable, fork-safe): resolve the PR, confirm an entitled CODEOWNER approved, then drop the label, set the status to success, and neutralize stale check-runs — one hop, no re-dispatch.

…he enforced budgets

The measureBest comment still claimed the streaming budgets carry 10x+ headroom that contention cannot eat — disproved by the 5s-default-timeout incident this branch fixes, and stale now that the XL budget is 15s (~4x observed CI cost) with explicit per-test timeouts.

The Table render benchmarks asserted tight budgets (100-200ms, 750ms CI) against a single wall-clock sample — the exact pattern facebook#3848 diagnosed as flaky under parallel forks and fixed in the Markdown perf suite, but Table.perf was left out. Apply the same best-of-3 technique: the fastest of three runs approximates the un-contended cost while a real regression still raises the minimum. Mount/unmount happen outside the timed section so only the measured work is sampled.