ROY-9: opt into threaded Slack DM replies per bot

[royko10]

What does this PR do?

Adds an opt-in dm_replies_in_threads preference per Slack bot installation. A top-level DM can receive its reply under that message; a follow-up keeps the existing thread root. DMs retain one continuous session per channel, and other installations keep their default behavior.

The preference is applied before ingestion, so replies and task delivery snapshots capture the originating thread. Delivery continues to use the task snapshot even after another input moves the binding cursor.

Related Issue

ROY-9: Reply to Slack messages in their originating threads.

Type of Change

• New feature (non-breaking change that adds functionality)
• Documentation update
• Tests (adding or improving test coverage)

Changes Made

• Persist the optional preference through the existing admin-only BYO registration API and expose it through the safe installation response.
• Apply the preference in the Socket Mode adapter without changing the DM session key or reinterpreting queued delivery destinations.
• Validate Slack installation responses in the shared API client, default the new field for older servers, and cover malformed responses.
• Cover default/disabled/enabled installations, existing roots, group isolation, reconnect persistence, and outbound snapshots after later DM inputs.

How to Test

1. go test -race ./internal/integrations/slack ./internal/integrations/channel/engine ./internal/handler from server/ with the checkout's isolated database: passed, including DB-backed delivery anchoring tests.
2. pnpm typecheck, pnpm lint, and pnpm test: passed. Lint reports existing warnings. Focused API compatibility suite: 106 tests passed.
3. git diff --check: passed. The new threaded-DM regression failed before implementation and passes afterward.

Full make test was attempted. It fails in unrelated CLI/config/daemon tests under the managed agent runtime (task markers/config isolation and daemon probe failures); all affected backend packages pass. The agent-provider half of that runner is not reached after the first half fails. No real-agent smoke tests or customer Slack messages were sent.

Rollout and risks

This PR does not change any live bot. After review and deployment approval, an owner/admin can re-register the intended agent's current Slack app through POST /api/workspaces/{workspace_id}/slack/install/byo?agent_id={agent_id}, using its current tokens and "dm_replies_in_threads": true. Keep credentials in the authenticated request; never place them in an issue or PR. The existing installation ID and Chat bindings remain intact. Read back the installation through GET /api/workspaces/{workspace_id}/slack/installations and verify the preference is true. The Socket Mode supervisor reloads the changed configuration on its next reconciliation.

There is no UI toggle in this scoped change. Re-registering with false, or omitting the field, restores the default. Native slash-command acknowledgments retain their existing behavior because their payload has no originating message timestamp. Scheduled delivery destinations are unchanged. Live Slack verification should be performed only after the separately approved rollout.

Checklist

• I have included a thinking path that traces from project context to this change
• I have run tests locally and they pass (affected checks pass; full Go-suite limitations documented above)
• I have added or updated tests where applicable
• I have updated relevant documentation to reflect my changes
• I have considered and documented any risks above
• I will address all reviewer comments before requesting merge

AI Disclosure

AI tool used: Codex via Multica (Mika).

Prompt / approach: Implement a default-off per-bot Slack DM reply preference while retaining session continuity and delivery anchoring. Reproduced the missing behavior, reused the existing task delivery snapshot contract, and ran routing, outbound, API compatibility, and repository checks. Deployment is a separate handoff.

[vercel]

@royko10 is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.