Fix #1014: faulthandler_timeout + step timeout so a hung pytest leg names its test

[fdaviddpt]

Closes #1014.

A Windows pytest leg was cancelled twice by the job-level timeout-minutes: 30 (PR #1013 job 114288023016, PR #1020 job 114358206393). A job cancelled
by its own timeout writes no log at all, so we could not tell which
test hung, or whether it was the runner or our code -- and this suite runs
real wscript.exe tests (#1002) that have already hung 40+ minutes once.

What changed

• pyproject.toml: faulthandler_timeout = 900 under
  [tool.pytest.ini_options] (built into pytest, no new dependency). Dumps
  every thread's traceback, naming the hung test, once any single test
  runs longer than 900s. Sized with ~30x margin over the slowest single
  test observed on a recent green windows-latest run (30.14s, run
  38091996750, job 114330142530), and below the new step timeout so the
  dump lands in a kept log.
• .github/workflows/tests.yml: a step-level timeout-minutes: 25 on both
  "Run tests" and "Run the full suite against the compiled hooks" -- below
  the job's 30-minute one, so a hang fails the step and the job still
  completes with its log (including the faulthandler dump), instead of
  being cancelled with no log at all. Output is tee'd to a file uploaded
  as an artifact under if: always(), and a trailing Windows-only step
  lists any surviving wscript.exe/bash.exe/conhost.exe/
  powershell.exe processes with PID/PPID/command line.

What is proven, and what is not

Proven (Linux): this PR's own round-2 proof -- a deliberately hanging
test, with faulthandler_timeout temporarily lowered and the step timeout
left in place -- was run on CI (run 38122057767, job 114445674357). The
faulthandler traceback naming the stuck test is present in the kept
log, followed by ##[error]The action 'Run tests' has timed out after 25 minutes.. That shows the step's own timeout-minutes is what keeps
the log -- pytest itself was not observed to exit before the step timeout
fired.

Not proven: faulthandler_exit_on_timeout (which would make pytest
_exit the process itself, well inside the 900s bound) was tried in an
earlier round-2 commit on this branch and then removed, because the proof
above gave no evidence it does anything before the step timeout already
ends the step -- it was never shown to fire first. And Windows was not
exercised by this proof at all -- only a Linux leg ran the deliberate
hang. The original failure mode #1014 was filed for (a Windows job ending
cancelled with no log, run 38122057767, job 114418645594: ~33.6 min past
the step's own 25-minute timeout) is therefore not shown fixed by this
PR. Filed as #1032 to track closing that gap with a Windows-side proof.

Earlier, separately-captured evidence that faulthandler_timeout itself
(the dump mechanism, not the step-timeout-keeps-the-log mechanism) fires on
both OSes: run 38103924282, a throwaway 8s-sleep test with
faulthandler_timeout = 5, produced the traceback on both
pytest (windows-latest, 3.10) job 114365322297 and
pytest (ubuntu-latest, 3.10) job 114365322191. That proof only showed the
dump firing, not that the step then ends the job with the log kept on
Windows under a genuine hang -- which is exactly the part #1032 tracks.

Compatibility checked

• --cov: faulthandler_timeout is independent of coverage collection;
  no interaction observed locally or in the proof runs (all ran with
  --cov active).
• pytest-xdist: a repo-wide grep found no xdist usage anywhere in this
  repo. faulthandler_timeout is a per-worker/per-process setting, so it
  would still work if xdist is added later.

Changelog

A changelog.d/1014.fixed.md fragment was added, since this does change
CI behavior observable to anyone whose pytest leg hangs (a log now exists
where none did before). The PR still carries the no-changelog label from
an earlier pass that judged this CI-only and therefore invisible to
end-users of the software; the maintainer may want to remove that label to
match the fragment, or drop the fragment to match the label -- noted here
rather than decided unilaterally.

CI

19/19 checks green on the finalizing commit (one round; no rerun needed).

[AI-generated]