* ci(build-exe): drop pull_request label trigger to avoid skipped checks
* docs(build-exe): sync agent note and pin event set in workflow spec
* test(ci): type-safe event key assertion for build-exe workflow
* ci(build-exe): use present-tense trigger comment and drop label-run note
The per-case 15-30s budgets on the Windows native and coverage lanes fire
before oxlint, workflow-worker-thread, and other subprocess-spawning cases
finish under the loaded self-hosted pool; the failures rotate across cases
as load shifts, so per-case widening only moved the flake. Raise the lane
defaults (DSH_COVERAGE_TEST_TIMEOUT_MS and the native --testTimeout) to 90s,
align the oxlint and workflow-worker-thread case budgets, and keep the
built-bin SPAWN_TIMEOUT_MS at 60s under a 90s outer budget.
Both suites spawn real subprocesses (oxlint probes; the dsh built bin) that
cold-start slowly on the contended self-hosted Windows pool, so their 20-25s
timeouts fire before the child finishes. Raise the oxlint contract case
timeouts to 60s and the built-bin execa timeouts to 60s, matching the
tool-ralph budget treatment.
The windows-* jobs keep a separate standalone pnpm executable under
runner.temp/setup-pnpm-js. A previous job on the same self-hosted runner
can leave a locked @reflink native module there, so the next job's
pnpm/action-setup fails with EPERM during unlink before any test runs.
Suffix the destination with run_id, run_attempt, and job so every job
gets a fresh directory even when sequential jobs land on the same
runner; apply the same to the python SDK exe build. Update the pnpm
setup isolation note to record the Windows-specific destination.
The full-corpus transform gate spawns one child that transforms and imports
every built bundle, so it runs for 8-25 minutes as a single case and
dominates one native Windows coverage partition, blowing its 900s budget
under load. Move it to the coverage-exempt heavy gate, which runs it with
its own worker budget instead of competing with the instrumented
partitions. The package's src is threshold-excluded in vitest.config.ts, so
the exemption carries no coverage; the exempt-heavy roster note records the
entry.