ci: dispatchable Windows race soak to hunt the one-off runtime crash

[deadpoets]

Diagnostic tooling for the open item from #53 — not a fix, and not a gate.

What it hunts

CI hit this once, on test (windows-latest) under -race (run 31982627382):

fatal error: stack not a power of 2
runtime.stackfree(...)  stack.go:468
runtime.gfget(...)      proc.go:5534
runtime.newproc1 / newproc  <- testing.(*T).Run

The runtime pulled a cached goroutine off its free list whose stack size is not
a power of two — runtime state that something corrupted. The secondary panic
showed a write access violation into read-only image memory, with g/m fields
holding image (0x140…) and Windows (0x7FF…) addresses.

Why tooling rather than a fix

Because I could not find the cause, and I would rather say so than ship a guess.

Read-cleared by mechanism, not by glance:

Suspect	Why it's cleared
scrubframe_amd64.s	Writes exactly [SP, SP+32768) — its own frame, guaranteed present by the prologue's stack check. Never touches R14 (g) or X15.
wipe_amd64.s secureWipe	Flush bounds computed before REP STOSB consumes DI/CX; aligned-down start stays in-page.
scrub_frame_test.go	Reads dead stack, never writes it.
terminationwipe.go	Pure Go, no unsafe.
Windows mapping path	Reserve rounded + 2*pageSize PAGE_NOACCESS, commit only the middle, VirtualFree on the reservation base. Guards are reserved-uncommitted, so a touch faults.
securearena.go AddCleanup	Closure captures only slabBytes and a uintptr key from regionKey; the janitor map holds the region, so no uintptr-as-live-pointer lifetime bug.
janitor.release	Both paths (take, then takeWiped) remove the region before freeing, so no dangling entry survives to be written through.

Not reproduced: ~500 local processes across Go 1.26.5 and 1.26.6, at
GOMAXPROCS=4 to match the runners, plus a GODEBUG=clobberfree=1 pass. No
upstream Go issue matches (golang/go#12192 is 1.4.2-era; #76786 is an unrelated
proposal).

So the remaining lever is sampling, on the image where it actually appeared.

What it does

Builds the race test binary once, then runs it N times on windows-latest with
GOTRACEBACK=system — the default traceback elides runtime frames, and the
runtime frames are the evidence. Failing output goes to the job log in a
::group:: and the first 40 lines to the step summary.

Dispatch inputs: iterations (200), gomaxprocs (4), godebug, package. So
a hypothesis can be tested without editing the file. Daily at 09:00 UTC, clear
of the 07:00 fuzz run. timeout-minutes: 90 so a hang cannot burn six hours.

Two things worth knowing

A green soak is not a clean bill of health, and the workflow says so in its
own summary output rather than leaving a green tick to be misread later. It
bounds the rate; it does not clear the defect.

workflow_dispatch only works once the workflow is on the default branch.
This has to merge before it can hunt anything — it cannot be exercised from this
PR, which is an argument for merging it early rather than late.

The header comment says to delete it once the crash is understood. A soak nobody
reads is worse than no soak, because it looks like coverage.

[deadpoets]

Landed on main as 3b6474c via the integration train in #55.

Now that it is on the default branch, workflow_dispatch will register and the daily 09:00 UTC schedule becomes active — it could not be exercised from its own PR.

Rebased locally so the commit carries the maintainer's SSH signature; different SHA, hence the manual close.