fix(gate): capture the log a failure points at, and stop leaking the server

[forkwright]

Closes #84
Closes #85

1. The failure log was missing the half that mattered (#84)

run_stage sent stdout to /dev/null, captured stderr, then named that stderr file in the failure detail. Which stream carries a diagnosis is per-tool, so I measured rather than assumed:

stage tool	failure output on stdout	on stderr
zola	0 B	195 B
lychee	80 B	13034 B
csp-enforce (failing)	0 B	356 B
pa11y-ci (failing)	1425 B	0 B

So for three of four the old capture worked. pa11y-ci is the real case: a failing accessibility stage emitted see $LOGDIR/pa11y.err pointing at an empty file, while all 1425 bytes of findings went to /dev/null.

Both streams now land in one .log, which also preserves interleaving a split pair cannot.

This corrects my own issue text, which asserted the diagnostics were generally on stdout. Measured, that is true only for pa11y-ci.

2. The server leak was worse than the issue said (#85)

The issue is that cleanup() only tracked the playwright server, so an interrupt during pa11y leaked that one. True — but while testing I found kill "$SRV_PID" never worked on any path, including success:

$ cd dir && python3 -m http.server 8123 &
$ SRV_PID=$!
  captured $! = 380629 -> bash          # the subshell, not the server
$ kill "$SRV_PID"
  AFTER kill $!: python3 http.server 8123 STILL RUNNING -> orphan

cd X && cmd & runs the list in a background subshell, so $! is the subshell and the server is its child. Killing the wrapper leaves the server holding the port.

This was live, not theoretical. A leaked http.server was found bound to 8080, reparented to init, still serving a public-local directory that had already been deleted:

cwd:    …/examples/sample-blog/public-local (deleted)
ppid:   2152  (systemd --user)

That is also why a second gate run would fail to bind the port.

Both servers now start with python3 -m http.server --directory public-local — no list, so $! is the server — and both are registered in the trap.

3. The header claimed fail-fast; it isn't

Every stage runs and failures accumulate into one report. That is the better behaviour for a gate — one pass surfaces every problem — so the claim is corrected rather than the code. (One bullet of #92.)

Verified

• full gate green against examples/sample-blog; every stage writes a non-empty .log
• after an interrupt: 0 real http.server processes, port 8080 free