Fixes #62571.

Problem

resolveSlackThreadStarter and resolveSlackThreadHistory in extensions/slack/src/monitor/media.ts swallow ALL errors via bare catch {} blocks at lines 450–452 and 542–544 respectively. Auth failures, rate-limit rejections, scope errors (not_in_channel, channel_not_found), and network blips all map to the same silent null / [] fallback. Operators have no way to distinguish "genuinely empty thread" from "Slack rejected our call", and thread-context hydration can degrade silently in production.

Why it matters

Thread starter/history hydration is called at the front of every new Slack thread session to populate context. When it silently returns null / [], the agent proceeds without the missing context and the operator sees no log line explaining why. The fix preserves that best-effort behavior but surfaces the reason.

What changed

1. extensions/slack/src/monitor/media.ts — imports logVerbose from openclaw/plugin-sdk/runtime-env and replaces both bare catch {} blocks with catch (err) { logVerbose(\... channel=${params.channelId} ts=${params.threadTs}: ${err}`); return null/[]; }. Matches the established pattern already used elsewhere in this extension (monitor/context.ts:285, send.ts:140, actions.ts:49`).
2. extensions/slack/src/monitor/media.test.ts — mocks logVerbose via vi.mock("openclaw/plugin-sdk/runtime-env", ...). Upgrades the existing resolveSlackThreadHistory throws test to assert the log call with channel/ts/reason. Adds a new describe("resolveSlackThreadStarter", ...) block with 4 tests (the function had no direct coverage): success path, empty-text skip, Error throw surfaces via logVerbose with channel + ts + reason, non-Error thrown value surfaces via String(err).

No behavior change for callers — they still receive null / [] on failure. The log is verbose-level, so no noise increase for normal operation.

Testing

• pnpm vitest run extensions/slack/src/monitor/media.test.ts → 35 passed (31 previous + 4 new).

What did NOT change (scope boundary)

• No change to the Slack client, the thread-starter cache, or the happy-path code in either resolver.
• No change to log level — stays at logVerbose (silent unless OPENCLAW_DEBUG is on), matching sibling slack logging.
• Error classification (permanent vs. transient) is deliberately NOT added here — that's a separate concern tracked on Slack message tool: agent loops on message_not_found / fileId errors, burns API quota #37544. This PR just makes the failure visible.

Root Cause

• Root cause: bare catch {} blocks added when the resolvers were first written, never updated as the Slack extension grew logVerbose for error-surface diagnostics elsewhere.
• Missing detection / guardrail: none — tests only asserted the fallback return value, never the log behavior.

Regression Test Plan

• Coverage level that should have caught this: Unit test
• Target test file: extensions/slack/src/monitor/media.test.ts
• Scenario the test locks in: when conversations.replies throws, logVerbose is called with channel + ts + reason, and the resolver still returns the fallback.