Fix Slack file shares and DM reply targeting

[HaiyiMei]

Summary

• allow Slack file_share message events through subtype filtering so attachment-only image/file messages reach the normal hydration pipeline
• render agent reply targets for Slack DMs as user:<sender-id> instead of channel:<dm-channel-id> so message-tool final markers settle the same user-keyed session as the inbound DM
• add regression coverage for both behaviors

User-visible symptoms

Slack images and files are silently ignored

• Sending an image, screenshot, or file to the bot can produce no acknowledgement and no reply.
• Attachment-only messages are affected most visibly, but a file upload with an initial comment is also delivered by Slack as a file_share event and can be dropped as a whole.
• Plain text messages in the same conversation continue to work, making the problem look like the bot lacks image/file support rather than an event-routing bug.

Internal tool-call transcript leaks into Slack DMs

• A normal DM reply can be followed by, or replaced with, raw runner output that should remain internal.

• The leaked content can look like:

  Ran clisbot message send --channel slack --account default --target ...
  └ { "ok": true, … }
  

• This is DM-specific: channel conversations are already keyed by channel ID, while inbound DMs are keyed by the peer user ID.

• The symptom may appear intermittent because it depends on settlement reaching pane fallback after the real message send --final was recorded against the wrong session key.

Reproduction

1. File/image message is ignored

1. Configure and start clisbot with Slack enabled, then open a DM or routed Slack conversation with the bot.
2. Upload an image or file, preferably without accompanying text.
3. Observe that Slack emits a message event with subtype file_share.
4. Observe that clisbot does not start the normal attachment hydration/agent run and sends no reply.

Expected: the event reaches attachment hydration and the agent receives the uploaded file/image.

Actual: subtype filtering rejects the event before attachment handling.

2. DM leaks message-tool metadata

1. Open a Slack DM with the bot and send a prompt that produces a normal agent response.
2. Inspect the generated reply instruction: before this patch it targets channel:D..., even though the inbound DM session is keyed as user:U....
3. Let the agent send its response with clisbot message send --final.
4. Observe that the send succeeds, but the final marker is stored under the channel-keyed session rather than the active user-keyed DM session.
5. When the active session settles, it does not see the final marker and falls back to captured pane output, exposing the Ran clisbot message send ... line and result metadata in Slack.

Expected: only the intended user-facing message is posted and the active DM run settles as final.

Actual: the final marker misses the active session and pane fallback can post internal command/result text.

Root cause

Slack file uploads arrive as message events with subtype file_share, but the generic subtype filter discarded them before attachment hydration.

Slack inbound DMs are session-keyed by peer user, while the generated agent reply command used the DM channel ID. A message send --final call therefore marked a different session, allowing pane fallback/tool transcript text to leak into Slack.

Validation

• bun test test/slack-message.test.ts test/slack-session-routing.test.ts — 19 pass, 0 fail
• bun run build — pass
• git diff --check — pass
• bun run check — 992 pass, 1 unrelated failure in zalo-personal zca-js wrapper > refreshes the stored session after session login succeeds; the same failure reproduces on a clean upstream main checkout (989 pass, 1 fail), while the test passes in isolation