fix(tasks): complete finalization when reconciler loses race to runner report

[cursor]

Bug and impact

In HA deployments, when a runner reports a terminal task status on one node while the runner reconciler on another node concurrently calls failTaskRunnerLost, the reconciler can win the cluster finalize lock. If the DB already has a terminal status, failTaskRunnerLost returned early without releasing pool/Redis state (running set, active-by-project, claims) and without setting End, running autorun children, or progressing workflows.

This leaves tasks showing as finished in the DB while still occupying concurrency slots until restart or manual cleanup.

Root cause

failTaskRunnerLost treated an already-finished DB row as a no-op after winning TryFinalize, but FinalizeRemoteTask on the other node then failed to acquire the lock and also did nothing. The e0ef3d05 backstop in finalizeRemoteTaskLocked only ran when FinalizeRemoteTask won the lock.

Secondary issues in requeueTaskRunnerOffline:

• TOCTOU between DB refresh and persist could requeue a task that another node had already marked running
• Failed UpdateTask left in-memory runner_id cleared while DB still had it, causing subsequent reconciles to mis-route the task as undispatched

Fix

• When failTaskRunnerLost observes a finished status after DB refresh, delegate to finalizeRemoteTaskLocked instead of returning
• Make finalizeRemoteTaskLocked skip re-finalization when End is already set (not only in HA mode)
• Re-check DB immediately before requeue mutation; roll back in-memory state on persist failure

Validation

• Added/updated unit tests in runner_reconciler_test.go for HA finalize race, requeue TOCTOU skip, and persist-error rollback
• go test ./services/tasks/... passes