feat(openworkflow, server, dashboard): add resume workflow run functionality and UI components

[vudc]

Closes #520

Supersedes #521, which I was unable to reopen (GitHub refuses the transition on both the GraphQL and REST endpoints, with no reason given). This PR is the same work, rebased onto current main and with the outstanding review items addressed.

Summary

Adds resumeWorkflowRun(workflowRunId) to the client and backend, flipping a failed workflow run back to pending so the worker picks it up on the next tick. Completed steps are served from the existing step-attempt cache and are not re-executed; the failing step starts with a fresh retry budget. A "Resume Run" button is wired up on the run-detail page of the dashboard.

Changes

Backend

• Backend.resumeWorkflowRun({ workflowRunId }) added to the interface, implemented for Postgres and SQLite. In a single transaction it flips status from failed to pending, clears error / worker_id / started_at / finished_at, sets available_at = NOW(), and deletes the run's unsuccessful step_attempts. Non-failed runs throw a clear error.
• ow.resumeWorkflowRun(workflowRunId) client method.
• New helper resolveResumeWorkflowRunConflict in core/workflow-run.ts.

Dashboard

• New RunResumeAction component with a confirmation dialog, following the existing RunCancelAction structure.
• resumeWorkflowRunServerFn in lib/api.ts, alongside cancelWorkflowRunServerFn.
• isRunResumableStatus helper in lib/status.ts (currently "failed" only).
• Button rendered next to the existing "Cancel Run" on the run-detail page.

Tests

• New resumeWorkflowRun() block in the shared testing/backend.testsuite.ts, so both SQLite and Postgres are covered. The previous revision tested only through worker/execution.test.ts, which runs against Postgres, leaving the SQLite implementation untested.
• Two end-to-end tests in worker/execution.test.ts: a happy path asserting the completed step is not re-executed, and a negative path for a non-failed run.

What changed since #521

Rebased onto current main, plus the following review fixes.

Only failed step attempts were deleted. StepAttemptStatus includes running, and sleep, signal-wait and child-workflow attempts stay in that state for their whole lifetime. A run can reach failed with one still running, and since step-history.ts builds runningByStepName from whatever attempts it loads, a surviving row made replay treat that step as in-flight instead of re-executing it. Resume now deletes everything that is not completed or succeeded. The new testsuite case fails against the old query, with the leftover running-step attempt surviving the resume.

started_at was not cleared. rescheduleWorkflowRunAfterFailedStepAttempt explicitly nulls it when sending a run back to pending; resume now matches.

SQLite transaction control flow. resolveResumeWorkflowRunConflict threw from inside the try, so the catch issued a second ROLLBACK on an already-rolled-back transaction, which better-sqlite3 rejects and the inner catch {} swallowed. BEGIN now sits outside the try (matching the other transactional methods in this file) and the conflict lookup happens after the transaction closes.

Postgres read outside the transaction. The conflict lookup called this.getWorkflowRun, which uses the outer connection. It now reads through tx, and the method uses the shared withTransaction helper rather than pg.begin with a cast.

Removed the flaky-payment demo. It drove failures from module-scoped mutable state in a workflow handler, which is not a pattern worth demonstrating and made the demo dependent on worker process lifetime.

Review items not changed, with reasoning

• RETURNING * returning snake_case columns. cancelWorkflowRun and markWorkflowRunFailed in the same file use the identical this.pg<WorkflowRun[]> plus RETURNING * pattern; the column transform is configured globally.
• Trigger button not wrapped in AlertDialogTrigger. RunCancelAction uses the same controlled open state with a sibling <Button>. Changing only the resume component would leave the two inconsistent. Worth doing for both in a separate PR if you would like.
• Dialog closing before an error can render. Same situation: the behaviour is inherited verbatim from RunCancelAction.
• No auth guard on the server function. Matches cancelWorkflowRunServerFn and the rest of the dashboard's server functions.
• flakyPayment.spec may not exist. Moot now that the demo is removed; it was the same access hello-world.run.ts uses.

Testing

tsc --noEmit is clean. The SQLite and core suites pass locally (370 tests). I was not able to run the Postgres-backed suites in my environment, so the Postgres path relies on CI.