[Fix] Follow-ups start disconnected tasks after delegated work completes

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

Fast now includes conversation-owned tasks with valid resumable snapshots in the same task list it already uses for active work. Canceled runs, failed snapshots, and expired snapshots remain excluded.

The follow-up itself uses the existing canonical task steering endpoint. That endpoint already resumes settled tasks from snapshots under the same task identity; this PR adds one lifecycle recheck when a live steer loses a race with settlement. Snapshot resume insertion is serialized transactionally by source run so only one worker can be restored from a given snapshot; a concurrent loser receives a retryable conflict. Concurrent GitHub comments route that conflict through the existing linked follow-up fallback, preserving the second instruction and posting its task response.

Why this change was made

Fast previously stopped listing a delegated task as soon as its run settled, so a user follow-up could be treated as new disconnected work even though canonical task steering could resume the existing task.

Impact

Users can continue recently settled delegated work through the same task and conversation without concurrent failures forking execution or silently dropping a GitHub instruction. Fast-specific behavior is limited to conversation-scoped task discovery and keeping cancellation restricted to active runs; message delivery, atomic snapshot restoration, persistence, and sandbox restoration remain canonical shared behavior.

[roomote-community]

No new code issues found. See task

• Discord follow-ups reuse a conversation-level delivery ID, so a second instruction can be acknowledged and dropped while a resume is pending. (packages/cloud-agents/src/server/fast-agent/fast-agent-service.ts:1127)
• Resumable-task discovery includes canceled and snapshot-failed runs. (packages/db/src/lib/task-run-continuation.ts:25)
• Concurrent steering failures after settlement can create multiple SnapshotResume runs from the same source snapshot. (apps/api/src/handlers/tasks/sendMessageToTask.ts:1281)
• Concurrent GitHub follow-ups can throw the new resume-conflict error, be acknowledged without a response, and lose the second instruction. (apps/api/src/handlers/github/handlePrComment.ts:1067)

_{Reviewed c49d651}

[roomote-roomote]

Resolved the concurrent GitHub follow-up loss in c49d651.

When another comment wins snapshot resume creation, resumeExistingTaskAndDeliverFollowUp now catches the typed conflict and returns through the existing GitHub fallback path. The handler then launches and links a dedicated PR follow-up task for the second distinct instruction and posts its task response, rather than letting the webhook absorb an exception.

Focused GitHub conflict-path and canonical API tests pass, affected typechecks and oxlint pass, and the full pre-push lint/type/knip gate succeeds.