feat: Slack ChannelBackend — first external channel transport

[mdproctor]

Context

First external ChannelBackend implementation after the Qhorus gateway lands (casehubio/qhorus#131).

Slack is the right first external backend:

• Developer-friendly setup (5 minutes to a working Slack app, no approval gatekeeping)
• Bolt/Events API well-documented with Java client support
• Maps naturally to the casehub use case: agents post status, humans observe and interject
• Validates the connectors architecture pattern for subsequent backends (WhatsApp, Matrix, etc.)

What this is NOT

Digest/summarisation logic does not belong here yet. The gateway delivers faithfully; only add batch digest if Slack-specific volume becomes a UX problem in practice.

Sequencing

Blocked on casehubio/qhorus#131 (gateway + ChannelBackend SPI). After that:

1. Implement SlackChannelBackend implements ChannelBackend
2. Outbound: post() → Slack Bolt message to configured channel
3. Inbound: Slack Events API webhook → gateway → normalised Qhorus speech act
4. Registration: channel metadata stores Slack workspace + channel ID

After Slack

WhatsApp backend is the right second external backend for consumer-facing/end-user scenarios (loan applications, support tickets, human-in-the-loop approvals from non-technical users). Higher setup friction — Meta Business verification, approved templates.

Refs casehubio/qhorus#131