Fix Fast image-only Slack follow-ups

[daniel-lxs]

What changed

• resolve the current Slack message's files from the event or thread history before deciding a Fast turn is empty
• treat an image-only Fast follow-up as a multimodal question instead of showing the !fast usage hint
• download at most three Slack images per Fast turn
• enforce the same three-image cap when building native OpenCode file parts

Why

Slack can omit file metadata from the event while returning it through conversations.replies. Fast already recovers that thread metadata for text-plus-image turns, but it decided an empty-text turn was invalid before fetching the thread, so image-only follow-ups never reached the model.

Bounding the images before download and again before inference keeps large Slack posts from creating unbounded multimodal payloads.

This supersedes the remaining useful behavior from #1446; the underlying native-session screenshot support already shipped in #1474.

Validation

• @roomote/api: 207 test files, 1,799 tests
• @roomote/cloud-agents: 99 test files, 775 tests
• pnpm check-types
• pnpm lint
• pnpm knip
• targeted ESLint for all five changed files

Smoke test

Mock Slack app-mention-fast passed against pushed head 50a39ba7 using OpenCode 1.18.10:

• a normal Fast root established the conversation
• an image-only follow-up with four real PNG attachments produced a visual answer instead of the usage hint
• the three-file selection is asserted at the Slack download boundary and again at native OpenCode file construction

[roomote-community]

No code issues found. See task

_{Reviewed 50a39ba}

[daniel-lxs]

Closing because this replacement was created from the same PR-number mix-up. No code from this PR was merged.