`slack_read_thread` parameter named `message_ts` instead of `thread_ts`

The slack_read_thread tool requires its parameter to be named message_ts. Elsewhere in the Slack ecosystem the same value is typically called thread_ts: it's the name in Slack's Web API, and it also appears in the permalinks returned by the search tools (?thread_ts=<ts>). We've observed LLM agents occasionally calling slack_read_thread with thread_ts instead of message_ts (likely pattern-matching from prior search output), and the server rejects those calls.

Reproduction:

1. Call slack_search_public_and_private with any query. The result permalinks contain ?thread_ts=<ts>.
2. Ask an LLM agent to read the thread for one of the results.
3. The agent calls slack_read_thread { channel_id, thread_ts: <ts> }.
4. The server returns initialization_failed: Missing value for parameter `message_ts` .
5. The agent retries with message_ts and the call succeeds.

Expected:

Either accept thread_ts as an alias for message_ts, or rename message_ts to thread_ts so the input matches the Slack API and the MCP's own response data.

Actual:

First call fails. Each occurrence costs roughly 750 ms plus the model tokens to read the error message and retry.

Note:

We've seen this on claude-opus-4-8 more than once. Since thread_ts is the canonical name in Slack's docs and the parameter that appears in the MCP's own response permalinks, any LLM client trained on Slack documentation is likely to default to it. A one-line server-side change to accept either name would fix it.

Start at the slack_read_thread tool definition and its parameter schema, then reproduce the call using the thread_ts value from a search permalink. Done means the tool accepts thread_ts, or both names, without the initialization error while the existing message_ts call continues to work.