fix(slack): use z.coerce.string() for timestamp fields to handle LLM numeric inputs

[blinkagent]

I opened this PR via Blink. It seems my Coder Assist agent (based on Scout) calls slack_sendMessage several times using a number timestamp before it figures out it needs to send a string. This delays the agent's response time in Slack quite significantly. -Matt

Problem

LLMs sometimes pass Slack timestamps as numbers instead of strings (e.g., 1234567890.123456 instead of "1234567890.123456"). The Slack API requires these to be strings, and without coercion, Zod validation would reject numeric timestamps causing slack_sendMessage and related tools to fail with type validation errors.

Solution

This change uses z.coerce.string() instead of z.string() for all timestamp fields (ts, thread_ts) to automatically convert numbers to strings, making the tools more robust to LLM output variations.

Affected tools

• sendMessage (ts field)
• reactToMessage (ts field)
• readMessage (ts field)
• readThreadReplies (ts field)
• reportStatus (thread_ts field)

Related

This is a known issue with Slack's API - see:

• chat.postMessage param thread_ts must be a string not a float slackapi/node-slack-sdk#780
• chat_postMessage accepts thread_ts as a float but does not create a thread slackapi/python-slack-sdk#840

[blinkagent]

CI Failure Analysis

The CI typecheck failures are not caused by my changes. They appear to be related to a dependency resolution issue in the CI environment.

Evidence:

1. The errors occur in multiple packages I didn't touch:

   • blink - MockLanguageModelV2 renamed issues, JSONValue type incompatibilities
   • @blink-sdk/compute - toModelOutput parameter type issues
   • @blink-sdk/github - toModelOutput parameter type issues
   • @blink-sdk/scout-agent - MockLanguageModelV2 renamed, rawFinishReason property missing
   • @blink-sdk/model-intent - MockLanguageModelV2 renamed
   • @blink.so/site - UIMessagePart type issues

2. Fresh install of main branch locally passes typecheck for @blink-sdk/slack (the only package I modified)

3. The lockfile is identical between main and this branch

4. My only change is using z.coerce.string() instead of z.string() for timestamp fields, which doesn't affect the inferred type (both result in string)

Root Cause

The CI is using bun-version: latest which resolved to v1.3.5, while the lockfile was likely generated with v1.2.14. This may be causing different dependency resolution, particularly for the ai SDK package which appears to have had breaking changes (e.g., MockLanguageModelV2 → MockLanguageModelV3).

Recommendation

This CI failure affects all PRs, not just this one. The repo may need to:

1. Pin the Bun version in CI to match the lockfile
2. Update dependencies to fix the type errors
3. Regenerate the lockfile with the newer Bun version