[Refactor] Generalize Fast conversation routing for Discord

[daniel-lxs]

What

• separate durable Fast conversation identity from the provider address used to post replies
• reuse one Fast session for Discord DMs and real Discord threads while keeping top-level guild invocations isolated
• deliver delegated-task artifact, pull-request, and settled events to the explicit Discord reply target
• keep launch_task available during Discord lifecycle turns through a shared Fast task launcher
• stamp Fast child ownership metadata atomically so child runtimes cannot also reply directly
• deduplicate retried Discord lifecycle messages with deterministic nonces
• derive lifecycle task-link attribution from the parent surface instead of assuming Slack

Why

Discord slash interaction IDs were serving two unrelated jobs: identifying Fast memory and identifying where later lifecycle messages should be posted. An interaction ID is not a Discord channel or thread, so a delegated task could retain the right parent session but later attempt delivery to an invalid destination.

The Fast conversation contract now models those concerns independently:

• conversationId scopes memory and turn serialization
• replyTarget is the provider-native channel/thread address

Fast child metadata is also constructed as one invariant: the parent stamp, session ID, and inherited-context flag are emitted together. This keeps lifecycle routing coordinates available while preventing the child runtime from treating them as its own direct reply surface.

Slack and Discord use the same contract and shared enqueue/kickoff mechanics, while provider-specific code only constructs the provider task payload and performs delivery.

Impact

• Discord Fast DMs and threads behave as continuous chat sessions.
• Top-level guild Fast invocations do not share memory with unrelated channel messages.
• Delegated-task lifecycle events return to the real parent channel or thread.
• A lifecycle turn can launch another task without a Discord-only runtime gap.
• Fast children cannot emit a second direct chat response alongside the parent lifecycle response.
• Retried lifecycle delivery does not duplicate the Discord message.

Validation

• pnpm lint
• pnpm check-types
• pnpm knip
• focused ownership suites: API 84 tests, SDK 8 tests, cloud-agents 3 tests, worker 17 tests
• full API suite: 206 files, 1,788 tests passed
• full web server/client suites: 389 files, 2,981 tests passed
• repository-wide test run passed all changed packages and stopped on one unrelated worker test whose premise is incompatible with this isolated checkout: it treats process.cwd() as outside /tmp, while the PR worktree itself is under /private/tmp

Mock Discord smoke

The checked-in Discord mock harness exercised a guild /fast request through delegation, child-thread creation, a settled child event, and Fast lifecycle closeout. The closeout posted to the real parent channel, and no request targeted the slash interaction ID.

A second focused guild /fast smoke inspected the persisted child payload. Both the initial child run and its automatic startup retry carried communicationContextInherited: true; the worker regression test resolves the same payload to no direct Discord reply context. The local compute provider failed before the child reached an agent turn, so this proves launch-payload ownership rather than a successful sandbox execution.

Temporary smoke fixtures were removed after verification.

[roomote-community]

No code changes since the prior review; 1 issue remains outstanding. See task

• packages/sdk/src/server/lib/fast-agent-parent-event.ts:357 Fast child launches now mark inherited communication context, preventing duplicate direct Discord lifecycle messages.
• packages/sdk/src/server/lib/fast-agent-parent-event.ts:415 Parent events now use the persisted Discord reply target instead of treating a message or interaction ID as a thread channel.
• packages/types/src/fast-agent.ts:21 Replacing the persisted Fast-parent conversation shape drops artifact, pull-request, and settled-event delivery for active runs created before deployment. — dismissed: the replaced payload shape has not shipped or been deployed.
• packages/sdk/src/server/lib/fast-agent-parent-event.ts:357 Discord Fast children can still publish request_user_input controls directly in their child thread, bypassing parent-owned delivery.

_{Reviewed 895cb9f}

[roomote-community]

communicationContextInherited suppresses the child runtime's normal reply environment, but it does not suppress worker request_user_input delivery. The worker still registers Discord RUI for every Discord payload, and publishCommunicationRequestUserInput posts to this child task's communicationChannelId/communicationThreadId without checking the inherited flag. A Fast-delegated Discord task that asks a question will therefore show its buttons in the child thread, splitting user-visible delivery away from the parent Fast conversation. Route that flow through the parent or skip the child-side RUI for inherited contexts.