test: parallel stress of the helper pool; docs: Zen 3 re-measurement

[tannevaled]

Test (no library code change)

TestParallelStress: 6 goroutines run the parallel kernels (Add, Mul, Sum, Max, Dot, MatVec, SumAxis, Exp, Sqrt) at once with the thresholds lowered, while another keeps changing GOMAXPROCS. The pool is contended, so some calls take the fork fallback. Every result is compared with the serial kernel on integer data, so the comparison is exact.

• Hang watchdog: a lost block hangs the call rather than corrupting it, so the test fails by name if a call does not return within its time budget.
• Sabotage, caught: a pool that skips each run's first block ("a parallel call never returned"), and a fork fallback that drops the last element ("[1643] parallel 0, serial 1").
• Passes: under -race; on real POWER9 (59,154 calls in 5 runs), X-Gene arm64 (65,798) and Loongson 3C5000L (36,174). Coverage stays at 100%.

Docs: Zen 3 is back up (cfarm421, idle)

Fresh process per case, v0.6.1 vs v0.5.2, median:

• 16 workers: Dot 2.08× (120 → 57 µs), MatVec 1.92×, Sum 4 Mi 2.07×, Max 256 Ki 2.36×.
• Losses: Chain 4 Mi at 16 workers 0.88×, Exp 256 Ki at 8 workers 0.85×.
• Against NumPy 2.5.3 / OpenBLAS with 16 threads, same run: Dot 0.69× and mat·vec 0.52×. The README said 0.16× (pre-pool) and is updated.

The table is in docs/perf.md; SECURITY.md has the audit-log entry for the stress test.

Docs + tests only: no tag.

🤖 Generated with Claude Code