Two more wall-clock growth-ratio tests flake under CPU load: test_issue_dependencies (3 of 20 runs) and the audit-event-catalog scan (1 of 20) #1059

Summary

Two more growth-ratio tests time a scan with the wall clock (time.perf_counter) and fail when the machine is busy. The same cause makes TestPatternLinearity flaky (#1047, nightly #72). Under CPU load:

• tests/test_issue_dependencies.py::test_reading_a_hostile_text_grows_linearly_with_its_length failed 3 of 20 runs;
• tests/test_check_audit_event_catalog.py (the test_scaling_is_linear_on_adversarial_input test) failed 1 of 20.

Neither pattern is super-linear: the tests mistake scheduler noise for growth.

Evidence

Measured on development at 735a02f (macOS, 18 cores, Python 3.13). 36 busy-loop processes ran during the measurement, with a load average of 41-81. Each selected test was run 20 times with pytest -k <test> -o addopts="", except the secrets test, which ran 10 times because one run takes about 70 s.

The other timing tests use absolute ceilings (100 ms or 1 s on 10K input), or apply the ratio only when the baseline is at least 1 ms. They stay far from their limits, and nothing here suggests changing them.

Why it matters

• tests/test_issue_dependencies.py runs in the full suite and again in CI's coverage step. That step enforces the 90 % floor for tools/issue_dependencies.py, a workflow script with a token that can write to issues. A flaky failure there blocks unrelated pull requests.
• The gauntlet in CLAUDE.md runs it twice, so a busy development machine fails the gauntlet for no reason, as TestPatternLinearity still fails on a busy machine: the wall-clock ratio check flakes (42.8x against a 20x limit) #1047 describes.

Proposed fix

Apply the approach decided for #1047 to these two tests:

• Measure CPU time (time.process_time()) instead of wall time, and keep the median.
• Calibrate the batch so that one timed sample lasts at least max(0.025, 8 * time.get_clock_info("process_time").resolution) seconds. On Windows the CPU clock ticks at about 15.6 ms, and publish.yml runs the suite on windows-latest.

Per test:

• test_issue_dependencies.py: _seconds_per_call uses a fixed repeat (20 for the small text, 2 for the large one). Replace it with a calibrated repeat count per input, and keep the 3x allowance.
• test_check_audit_event_catalog.py: time a calibrated batch of search calls per size instead of one call, and keep the 30x limit and the 1 s floor.

Do not add retries, skips or looser limits.

Acceptance criteria

• Both tests measure CPU time with a calibrated batch, as above.
• Each test gains a negative control showing that a quadratic reader or pattern still fails the ratio check, like test_quadratic_scan_is_still_rejected in tests/test_check_source_path_refs.py.
• Evidence in the pull request: 20 runs of each test under CPU load (for example 40 busy loops: for i in $(seq 1 40); do timeout 300 python3 -c 'while True: pass' & done) pass, with the min/max ratio before and after.
• python3 -m coverage run --source=tools -m pytest -q -p no:cov -o addopts="" tests/test_issue_dependencies.py tests/test_assign_on_comment.py tests/test_triage_gate.py still reaches the 90 % floor.

Context

Same root cause as #1047 (which keeps its own scope: TestPatternLinearity only) and #72. Do the two together, or do #1047 first, so that all three tests share one approach. docs/standards/regex.md ("median of N runs") stays true.