Don't reap executions that are waiting on a child

[AbirAbbas]

An execution's updated_at stops moving while it waits for a child to return, so the staleness sweep read "blocked on a child" as "stuck". Any agent that does many minutes of work inside a single request had its whole ancestor chain marked timed out mid-flight — the caller got execution timed out (no activity) while the work was still running, and the agent went on to finish normally against a run already reported as failed.

Observed on a real build: the root execution was marked failed at 20:15:46, and the agent doing the work kept emitting progress until 20:46 and beyond. A comparable build whose work was split across many short reasoner calls succeeded in the same window — each call bumped updated_at, so it never looked idle.

This is the invariant the code already documents ("callers must ensure updated_at is bumped on every meaningful execution activity") meeting a caller that legitimately cannot bump it, because it is blocked.

Change

Rows with a non-terminal child are skipped by both sweeps (MarkStaleExecutions and MarkStaleWorkflowExecutions had the same shape). parent_execution_id already exists and is indexed on both tables.

There is deliberately no recency test on the child, which is what makes the rule safe for arbitrary nesting depth: the chain drains bottom-up. If work genuinely stops, the leaf goes stale and is reaped first, which makes its parent childless and eligible on the next sweep, and so on up to the root. One sweep per level, and nothing is stranded in running. Requiring the child to be recently active instead would only protect one level and would still reap grandparents.

Tests

internal/storage/stale_execution_parent_test.go covers:

• a three-level chain where only the leaf is working — nothing is reaped
• the same chain fully idle — drains one level per sweep, leaf first
• a terminal child does not shield a genuinely stuck parent
• an unrelated stuck execution is still reaped in the same sweep as a protected chain

Both new behavioural tests were confirmed to fail with the fix reverted, so they pin the behaviour rather than the implementation.

go build ./... and the full ./internal/storage/... suite pass, existing reaper tests included.

🤖 Generated with Claude Code

[github-actions]

📊 Coverage gate

Thresholds from .coverage-gate.toml: per-surface ≥ 84%, aggregate ≥ 85%, max per-surface regression ≤ 1.0 pp, max aggregate regression ≤ 0.50 pp.

Surface	Current	Baseline	Δ
control-plane	87.00%	87.40%	↓ -0.40 pp	🟡
sdk-go	92.70%	92.00%	↑ +0.70 pp	🟢
sdk-python	93.82%	93.73%	↑ +0.09 pp	🟢
sdk-typescript	91.05%	90.42%	↑ +0.63 pp	🟢
web-ui	84.76%	84.79%	↓ -0.03 pp	🟡
aggregate	85.59%	85.75%	↓ -0.16 pp	🟡

✅ Gate passed

No surface regressed past the allowed threshold and the aggregate stayed above the floor.

[github-actions]

📐 Patch coverage gate

Threshold: 80% on lines this PR touches vs origin/main (from .coverage-gate.toml:thresholds.min_patch).

Surface	Touched lines	Patch coverage	Status
control-plane	12	100.00%	✅
sdk-go	0	—	➖ no changes
sdk-python	0	—	➖ no changes
sdk-typescript	0	—	➖ no changes
web-ui	0	—	➖ no changes

✅ Patch gate passed

Every surface whose lines were touched by this PR has patch coverage at or above the threshold.