[sbalabanov]

Why?

buildsignal holds a nonterminal build on every poll, and holds do not consume the retry budget, so a runner that keeps answering accepted or running is re-polled forever. Nothing dead-letters and nothing releases the build slot. Repro:

1. Run a queue with MaxConcurrent 1.
2. Its build's runner reports running on every poll, so the buildsignal message holds and redelivers indefinitely.
3. A newer head is accepted and waits at the process gate behind it.
4. Nothing ever fails the build, so the queue's only slot stays held forever.

What?

Build gains CreatedAt, which build sets at creation and MySQL persists in a new build.created_at column. QueueConfig gains MaxValidationMs (zero disables the deadline). The reference default store sets it to two hours. When a poll leaves the build nonterminal past the deadline, buildsignal runs the same terminal sequence as a polled failure and marks the request failed with reason validation_timeout (stored on the request by #965). The timed-out build established nothing: it keeps its last polled status, the request's TerminalBuildID stays empty, and there is no build_finished entry or terminal analysis publish. Existing MySQL deployments must add created_at BIGINT NOT NULL DEFAULT 0 to build first.

Convergence: a retry after any failure in the timeout sequence polls again, finds the build still nonterminal and still past the deadline, and takes the same path with the same reason; finishRequest is a no-op once the outcome landed. If the build reached a real terminal status in the meantime and the request has no outcome yet, that real verdict is recorded instead. Nothing lists nonterminal builds and the request is terminal, so nothing reopens.

Test Plan

make fmt && make lint && make check-tidy && make check-gazelle && make check-mocks
./tool/bazel test //stovepipe/... //service/stovepipe/... --test_output=errors && ./tool/bazel test //test/integration/stovepipe/extension/storage/mysql:go_default_test --test_output=errors

Stack

1. fix(stovepipe): persist the terminal outcome reason on Request #965
2. @ this PR

Audit: SP-OCT-002 in doc/audit/stovepipe-fable-v2.md (Sol v2 #12, Opus v2 #4).

🤖 Generated with Claude Code

[sbalabanov]

Two things for the reviewer, neither blocks CI:

Default value needs a human call. max_validation_ms defaults to two hours in the reference queue config store. Nothing in the repository establishes what a full-repository validation takes, so this number is a guess that bounds a hung build without cutting a long real build short. Zero disables the deadline. If you want a different default, say which and I will update the constant; otherwise it ships as is.

Merge order. This PR is stacked on #965. It also touches finishRequest and its doc comment in buildsignal.go, and the lease paragraph in process.md, which #966 rewrites independently. Whichever of #966 and this stack lands second needs a small rebase; I can do that once the first one merges.

[sbalabanov]

Closing without merging. If a bound turns out to be necessary, it will be a single deadline per whole request (admitted to terminal), not a per-build or per-external-system timeout. The build-runner poll is the only unbounded wait today, so one request-level deadline with one setting per queue covers it and any future asynchronous stage. Until then a too-old nonterminal build stays an operational alert, as the buildsignal RFC states.