test: make the time_limit hang guard robust to slow runners (#1058)

[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — N/A, no pcapkit/ change; isort -l100 clean on touched files
• A test case covers the change; the 12 affected modules and tests/project pass one module per process (full make test not run)
• Added a changelog entry — N/A, test-only

What is the purpose of your pull request?

• test — tests only

---

Description

Closes #1058. time_limit now defaults to 30 s (was 5 s, which bodies of ~5 ms still overran on a loaded runner). The 19 time_limit(5) sites take the default, and the three CASE_TIMEOUTs rise from 10 s to 30 s, matching EXTRACT_TIMEOUT/DEADLINE. PCAPKIT_TEST_TIMEOUT_SCALE multiplies every deadline, including DEADLINE's subprocess timeout. A malformed value raises; it is not ignored. CI does not set it (this PR doesn't touch .github/), so the 30 s default has to be safe without it. That bound is about 4000× a working body, and still well under #1059's 900 s per-test pytest-timeout.

ABC growth: real, but it does not explain the overrun locally. Over 40 purge_modules(['pcapkit']) cycles, the collections.abc.Mapping subclass tree grows from 950 to 2822–3758, oscillating rather than climbing because gc reclaims old generations. A gc.collect() per cycle holds it at 2822. An uncached isinstance(x, Mapping) scales with it, from 0.8 ms to 3–4 ms. In a 7-module internet slice in one process, the tree reached 5633, yet the slowest time_limit body was 6.9 ms (the issue's test). One module alone: 4.8 ms. The 5 s CI overrun is about 700× that, so runner stall is the likelier cause. UNVERIFIED: not reproduced.

[JarryShaw]

Cross-review verdict on e29a90f14: NEEDS CHANGES (ran on Sonnet; author Opus).

Required. A huge PCAPKIT_TEST_TIMEOUT_SCALE (1e9 or more) leaks the SIGALRM handler. scale_timeout accepts it, and then signal.alarm(seconds) at tests/_support.py:132 raises OverflowError: Python int too large to convert to C int. That line comes after signal.signal(SIGALRM, expire) at :126 but before the try at :134, so the previous handler is never restored. Move the arming inside the try, or clamp/reject oversized values in scale_timeout, and add a test for it.

Optional. tests/project/test_release_gates.py:2177 and :2320 still pass a fixed timeout=10 to subprocesses. These are the last tight bounds that ignore scale_timeout.

Confirmed:

• A busy loop fails at 30.0 s, and at 3.0 s with scale 0.1.
• 0, -1, nan, inf and abc raise before arming.
• Nested deadlines still restore correctly with a scaled value.
• No 5 s or 10 s time_limit call remains.
• The setUp env patch can't leak.
• ci: bound unittest-leg reimport growth and add stall diagnostics (#1052) #1059's pytest-timeout uses thread mode at 900 s, so it doesn't conflict.
• test_support_helpers 30 passed; test_ipv4_unit 26 passed.

[JarryShaw]

Cross-review verdict on e834a2921: GOOD TO GO (ran on Sonnet; author Opus)

• scale_timeout refuses a scaled deadline above the 86400 s ceiling before rounding. Scales 1e9, 1e308, nan and inf raise ValueError; exactly 86400 is accepted.
• signal.alarm is now armed inside the try. With alarm forced to raise, the previous handler came back and an enclosing 50 s alarm was still pending.
• Against the old helper, the new tests in tests/test_support_helpers.py give 4 failed, 31 passed. At this head the module gives 32 passed and 21 subtests passed, re-run independently.
• Nit, not blocking: signal.signal(SIGALRM, expire) still runs before the try. Only an exception in that gap (a KeyboardInterrupt, say) could leave expire installed.