feat: add file upload command

[danielbayer]

Summary

• Adds a dedicated file upload subcommand as a more discoverable alternative to message send --attach
• Supports uploading one or more files to channels, DMs, and threads with an optional comment
• Reuses the existing uploadLocalFileToSlack() from src/slack/upload.ts
• Follows the same target resolution and auth patterns as other commands

Usage

# Upload a file to a channel
agent-slack file upload "#general" ./report.md

# Upload with a comment
agent-slack file upload "#general" ./report.md --comment "Here's the coverage report"

# Upload to a DM by user ID
agent-slack file upload U08GDK5PBLG ./report.md

# Upload multiple files
agent-slack file upload "#general" ./report.md --attach ./data.csv

# Upload into a thread
agent-slack file upload "#general" ./report.md --thread-ts 1234567890.123456

Test plan

• bun run typecheck passes
• bun run build passes
• Manual test: upload single file to channel
• Manual test: upload to DM
• Manual test: upload with --comment
• Manual test: upload multiple files

[AmethystLiang]

Thanks for putting this together. I agree with the underlying problem: file uploads through the CLI should be easier to discover.

After looking through the implementation, I do not think we should add a new top-level file upload command right now. message send already supports file-only uploads through optional text plus repeatable --attach, so this would give us a second public API path for the same behavior and duplicate the target/workspace/thread/upload plumbing we need to maintain. I want to keep the library surface area small unless the new command unlocks a distinct capability.

I opened a docs-only PR that keeps your discoverability improvement but documents the existing path more clearly: #96. It covers file-only uploads, uploads with an initial comment, thread uploads, and multiple attachments via agent-slack message send ... --attach.

I am going to close this PR in favor of #96. If the documented path still proves hard for agents/users to find, I would reconsider this as a very thin alias over message send --attach, but I do not want to merge a separate implementation for it yet.