[Fix] Independent Slack suggestions share one execution thread

[roomote-roomote]

​Created by Roomote. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Accepted Slack task suggestions now create one top-level execution thread and one Session per suggestion instead of reusing the automation report Session.
• The execution thread is persisted on the suggestion card before dispatch so stale acceptance retries reuse the same root, while the work-item claim and a stable launch key prevent duplicate work.
• Execution-root writes and cleanup carry the claim token and exact channel/thread coordinates. A stale claimant cannot overwrite or delete a newer claimant's root, and failed launches clear a root only while they still own both records.
• The reacted card receives the eyes acknowledgement before launch. Slack's already_reacted response is treated as idempotent success, while other acknowledgement failures still stop the launch.
• Origin Session metadata and source-task links remain provenance, not execution-routing authority. Setup/onboarding suggestion routing and non-Slack providers retain their existing behavior.

Why this change was made

Independent suggestions from one automation report could be accepted into the same Slack thread and Session. That mixed unrelated task history and allowed mutable routing for one task to affect announcements, progress, completion, and follow-up messages for another. Retry races also needed explicit ownership fencing so recovery could not block on an existing acknowledgement or remove a newer launch's active root.

Impact

Each accepted repository-task suggestion has an isolated conversational history and a stable Slack destination for its full lifecycle. This intentionally replaces origin-thread reuse for accepted independent work while remaining compatible with the publication provenance and acknowledgement work in #2440 and #2354. The changed behavior is backend Slack routing and concurrency control, so browser proof is not applicable; focused provider-boundary tests cover the retry cases.

[roomote-community]

No code issues found. See task

• Retry recovery treats an existing eyes reaction as a failed acknowledgement (apps/api/src/handlers/slack/events/reactions.ts:631).
• A stale claimant can clear and delete a newer launch's execution root (apps/api/src/handlers/slack/events/reactions.ts:587).

_{Reviewed 7d1ba6e}

[roomote-roomote]

Addressing both retry-safety findings on the existing PR branch: idempotent eyes acknowledgement and ownership-fenced execution-root cleanup.