[Fix] Slack tasks post duplicate kickoff messages

[roomote-roomote]

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

What changed

• Launch Fast-delegated children as standard tasks with inherited read-only origin context instead of Slack-owned tasks.
• Remove all chat lookup, reply, reaction, and channel-posting tools plus live communication environment and lifecycle prompts from Fast children; keep artifact tools available.
• Post and persist the single Fast parent kickoff before the deferred child is made runnable; failed kickoff delivery or persistence prevents queueing.
• Route child idle, completion, failure, and cancellation states through a parent-owned lifecycle notifier and persist those updates in the Fast session.
• Relay each uploaded Fast-child artifact version immediately through the Fast parent with its versioned artifact link.
• Deduplicate publication retries and replayed events by artifact UUID, use Slack request idempotency for concurrent/crash retries, and commit delivered/session/audit bookkeeping atomically.
• Retry transient upload-completion notification failures against the same artifact version instead of creating another version.
• Preserve Fast-parent metadata, communication isolation, and artifact relay across direct and multi-hop snapshot resumes.
• Recover active Fast children by parent session metadata so later user turns can steer or cancel the task without giving the child direct Slack ownership.
• Remove the superseded acknowledgement-only parentOwnsKickoff mechanism.

Why this change was made

Fast delegation previously gave both parent and child authority to narrate the same Slack lifecycle. Suppressing only the child's first acknowledgement still left Slack capabilities available, introduced a race before the parent kickoff was delivered, lost isolation on snapshot resume, and left child artifacts visible only inside the task.

Impact

The Fast parent is now the sole owner of Slack-visible kickoff, lifecycle, and artifact updates. Fast children cannot read or post chat messages directly, including after snapshot resume, and they are not made runnable until the parent kickoff is durable. Each published artifact version appears promptly in the originating Slack thread without waiting for settlement. Independently launched non-Fast Slack tasks and artifact uploads retain their existing behavior.

Related PRs

• Revert of the Fast Brain preflight change: [Fix] Fast mode misses semantic Brain context on first lookup #1423

[roomote-community]

No code issues found. See task

• Normal Slack task starts suppress their initial acknowledgement because the no-ack policy is applied unconditionally.
• A Fast child can suppress its acknowledgement before the parent kickoff has actually been posted.
• Fast-child lifecycle updates are treated as delivered when Slack returns no message timestamp.
• Fast-child communication isolation and parent lifecycle routing are lost after a snapshot resume.
• A suppressed parent reply can still satisfy the Fast task kickoff gate and queue the child without any visible or persisted kickoff (apps/api/src/handlers/slack/events/fast-agent.ts:178).

_{Reviewed d6beb2b}

[roomote-roomote]

Added incremental Fast-parent artifact relay in 4eb171c. Every uploaded child artifact version is posted promptly with a versioned link; same-version replays deduplicate, concurrent/crash retries reuse the artifact UUID as Slack client_msg_id, delivered/session/audit writes commit atomically, and transient publication failures retry the same upload-completion event. Snapshot-resumed Fast children retain relay metadata; non-Fast uploads remain unchanged; settlement/task-link updates are preserved. Focused SDK, API, worker, and Slack tests passed with typechecks and the pre-push suite.