Slack: message.read ignores threadId (returns channel history), + Socket Mode events sometimes not handled

Environment

• OpenClaw: 2026.1.29
• Slack mode: socket mode (also observed in general Slack usage)
• macOS: Darwin 25.3.0 (arm64)

A) Bug: message tool action=read w/ threadId does not return thread replies

Repro

1. In Slack, pick a channel and create a thread with multiple replies.
2. Call the tool:

   {
     "action": "read",
     "channelId": "C123...",
     "threadId": "<thread_root_ts>",
     "limit": 20
   }

3. Observe the returned messages.

Expected

• Returned messages are the thread replies for threadId (Slack conversations.replies) or equivalent.

Actual

• Returns channel history (as if threadId was ignored).

Root cause

In OpenClaw v2026.1.29, the Slack channel is implemented as an extension:

• extensions/slack/src/channel.ts

That file’s if (action === "read") handler calls handleSlackAction({ action: "readMessages", ... }) but did not pass through threadId from tool params.

So message.read effectively behaved as if threadId was missing, falling back to channel history.

Minimal fix

In extensions/slack/src/channel.ts, forward threadId in the read action handler:

• read threadId = readStringParam(params, "threadId")
• pass it into handleSlackAction({ action: "readMessages", ..., threadId })

Suggested test

Add a vitest unit test that mocks handleSlackAction and asserts that slackPlugin.actions.handleAction({ action: "read", params: { ..., threadId } }) forwards threadId.

B) Socket Mode: connected but inbound events sometimes not triggering agent handlers

Symptoms

• Socket mode shows as connected.
• Messages in Slack sometimes do not trigger the agent reliably.

Diagnostics observed

When instrumenting socket mode receiver event logging, at least one inbound event produced a parsed "envelope" where key fields were null (e.g., type/payload fields missing), suggesting the "message" event seen by the receiver might not consistently be a standard Socket Mode envelope or might be emitted from a different layer than expected.

Request

• Add/keep lightweight receiver diagnostics to clarify whether Bolt is receiving Socket Mode envelopes but not dispatching handlers.
• Verify correct event emitter hook (SocketModeClient vs WebSocket raw message) for the Bolt version being used.

(If you want, I can provide redacted logs / a more specific summary of the observed event shape.)