Approval-gated action interrupted before its result is saved can never be retried #134

Problem

If the server stops between claiming an approval-gated MCP action (claimAction) and saving its result (finishAction), that (threadId, toolCallId) is bricked: every retry returns 409 This action is already running. forever, because mcp_actions rows have no expiry and there is no code path that clears a result-less running row.

Worse, the owner has no way to retry from the UI: the action card polls the receipt every 2s, sees status: running, shows "Running / This action is still running on the server.", and hides the Approve buttons while running is true. The card sits on "Running" forever with no affordance.

Reproduction

1. Start OpenDots (local npm run dev, Node v22.23.1) with a Dot that has an MCP connection with a gated (non-read-only) tool.
2. Have the Dot call the gated tool so the owner gets an approval card.
3. Approve it, and kill the server process after the claim INSERT but before the result UPDATE lands (equivalently: INSERT INTO mcp_actions(threadId,toolCallId,connectionId,tool,status,result,createdAt,approvalId) VALUES('thread','tc1','c','tool','running',NULL,<now>,'<approvalId>');).
4. Restart the server and open the conversation.
5. The card shows "Running" forever; approving/refreshing never completes. POST /api/conversations/thread/connection-actions with the same approval returns 409 {"error":"This action is already running."} on every attempt, until the approval itself expires an hour later.

Expected: after the in-flight run is demonstrably gone, the receipt should surface the interruption and the same approval should be able to run the stored request again (the request is already bound to its exact connection/tool/arguments, and only that approval may reclaim it).

Actual: misleading "already running" 409 with no self-healing and no owner retry path.

Notes

• MCP tool calls are bounded to 60s (ConnectionService timeout), so a result-less claim older than a few minutes cannot belong to a live run.
• The fix must preserve the double-claim guard: a fresh running row must still 409 (double click / retried request must not execute twice), a saved result must still be returned only to its own approval, and a different approval must never steal the claim.