Reject GitHub PR effects after cancellation

[dispatch-developer]

Summary

• require active execution states when authorizing GitHub PR-effect registration and reporting
• add Postgres regression coverage for cancellation during an active lease

Testing

• corepack pnpm typecheck
• corepack pnpm typecheck:test
• corepack pnpm test:e2e -- test/e2e/supplied-wake-context-persistence.test.ts (blocked: no container runtime; the configured suite also ran all e2e tests and failed where Docker/Helm are required)

Fixes #150

[dispatch-developer]

Hourly maintenance: review routing was not applied because the head commit's combined status is still pending (despite completed successful CI, CodeQL, and Dependency Review checks). Please investigate the pending required-status condition before review routing.

[dispatch-reviewer]

The fix is correct and the new regression test covers both affected paths precisely.

SQL changes (src/runtime/postgres.ts)

registerGitHubPullRequestEffect — The added predicate AND execution.state IN ('PROVISIONING','RUNNING') is placed correctly in the locked-row query that gates the entire registration path. After requestExecutionCancellation is called on a PROVISIONING or RUNNING execution the execution transitions to CANCEL_REQUESTED (the deferred path — no immediate CANCELLED for active workers). The lease on the attempt is still technically valid at that point, but CANCEL_REQUESTED is not in the allowed set, so the query returns zero rows and the "Execution effect capability is not current" error is thrown before any INSERT can reach the effects table. That is exactly the right behavior.

reportGitHubPullRequestEffect — The new JOIN dispatch_executions … AND execution.state IN ('PROVISIONING','RUNNING') is structurally symmetric with the registration guard. The effect row is only locked and read when the execution is in an active state, so a cancelled (or cancel-requested) execution cannot have its already-registered effect reported after the fact. The FOR UPDATE OF effect lock scope is unchanged — only the effect row is exclusively locked, not the execution, which is consistent with the rest of the method.

Test coverage (test/e2e/supplied-wake-context-persistence.test.ts)

The new test exercises two independent sub-scenarios using separate executions:

1. Registration blocked after cancellation — Calls requestExecutionCancellation while the execution is in PROVISIONING (freshly claimed, never transitioned to RUNNING). This produces CANCEL_REQUESTED, leaving the lease valid but the execution state disqualified. Then asserts both the thrown error and that zero effect rows were written. Clean.

2. Reporting blocked after cancellation — Registers the effect successfully (correct: execution is still PROVISIONING at that point), then cancels, then attempts to report. Asserts the "capability is invalid" error and that the effect row remains in REGISTERED state with all PR fields null. The effect row cleanup (DELETE) is performed at the end. Clean.

Both executions are already in a cancelled/cancel-requested terminal state by the time the test ends, so no dangling state is left in the database.

CI

All 331 unit tests pass, both typechecks (typecheck and typecheck:test) are clean, pnpm audit --prod --audit-level high reports no vulnerabilities, and all required checks (CI, Dependency Review, CodeQL) are green.