feat(integrations): reference Slack Connect channel bridge

## Problem

Buzz has a Slack workspace history importer in progress (#2704), but no small,
operator-run reference integration for teams that need to keep collaborating
with customers or partners in Slack Connect while adopting Buzz.

Putting Slack tokens and workspace-specific behavior inside `buzz-relay` would
couple the relay to one vendor and expand its credential/security boundary.

## Proposed slice

Add a standalone `examples/slack-connect-bridge` binary that uses Buzz's
existing signed-event/WebSocket surface and Slack's Events/Web APIs.

The first reviewable slice would provide:

- explicit Slack `(team_id, channel_id)` to Buzz channel UUID mappings;
- two-way live text messages;
- thread preservation in both directions;
- Slack request signature verification and replay-window enforcement;
- Slack Connect validation (`is_ext_shared`) by default;
- loop prevention and durable Slack timestamp ↔ Buzz event ID mappings;
- `channel_id_changed`, `channel_shared`, and `channel_unshared` handling;
- bounded queues, Slack 429 retry handling, health endpoint, and structured
logs that never include credentials or full message bodies;
- an app manifest, example config, deployment/security documentation, and unit
tests.

The bridge would publish under its own Buzz bot identity and visibly label
proxied authors. It would not impersonate Slack or Buzz users.

## Security defaults

- Slack bot token/signing secret and Buzz private key come from environment
variables, never the JSON mapping file.
- Only configured channel pairs are accepted.
- Non-Slack-Connect channels are rejected unless an operator explicitly opts
in.
- A `channel_unshared` event pauses the affected route.
- The HTTP listener defaults to loopback; operators must deliberately expose
the Slack events endpoint through TLS.
- The bot must be a member of every mapped Buzz channel and Slack channel.

## Non-goals for the first PR

- Slack workspace history migration (covered by #2704)
- identity binding or impersonation
- files, reactions, edits, deletes, huddles, or DMs
- automatic Slack Connect invitation/approval
- relay-core changes or new Buzz event kinds

## Relationship to other work

- Complements #2704: that PR migrates history; this bridge handles live
coexistence.
- Does not depend on #2756: the bridge speaks the existing Buzz relay protocol
directly so it remains useful even if the proposed transport seam changes.
- Follows the external-integration direction discussed in #2754 while keeping
the relay core vendor-neutral.

I plan to follow this issue with a focused PR containing the binary, tests,
manifest, example configuration, and operator guide.