Address review feedback on #3414:

1. Multi-tenant key collision (security FIX). `ThreadKey` was
   `(channel, thread)` only; two Slack workspaces (account_id A vs B)
   producing the same `thread_ts` collided in the registry, letting
   account A's claim shadow account B's distinct conversation. New
   shape `ThreadKey { channel, account_id: Option<String>, thread }`,
   constructor takes `(channel, account_id, thread)`. Empty account_id
   normalizes to `None` so single-tenant traffic keeps a stable key.

2. Unbounded registry growth (quality BUG / security FIX).
   `sweep_expired` had no caller — `decide` evicted only on access, so
   a daemon in a Slack workspace with churning `thread_ts` accumulated
   stale entries until restart. New
   `BridgeManager::ensure_thread_ownership_sweep_started`, armed
   lazily on the first `start_adapter` call (so the sync constructor
   stays runtime-free for unit tests), runs a 60-second
   `tokio::time::interval` tied to `shutdown_rx`.

3. REST push bypass (Explore BYPASS-RISK → BYPASS-OK with explicit
   doc). `push_message` (cron / workflow / `agent_send` / REST `/push`
   outbound) intentionally does **not** consult the registry: the
   caller has already chosen who is sending, so there is no routing
   decision to gate. Added a doc-comment explaining the asymmetry and
   pointing to the follow-up path (opt-in
   `respect_thread_ownership` parameter) if user-visible pain shows
   up.

4. Test coverage. Added `distinct_accounts_do_not_collide_on_same_thread_id`
   and `empty_account_id_normalized_to_none` in `thread_ownership::tests`,
   plus `multi_tenant_account_id_flows_into_thread_key` in
   `bridge::tests` so the helper actually exercises the new metadata
   read. The bridge-side helper still mirrors the gate's logic — the
   acknowledged debt of a real-dispatch integration test (drives
   `dispatch_message` end-to-end with a stub `ChannelBridgeHandle`) is
   captured in the helper's doc-comment for follow-up.

Pre-flight: `cargo clippy --workspace --all-targets -- -D warnings`
clean, `cargo test -p librefang-channels --lib --no-fail-fast` 843
passed (3 new — 2 in `thread_ownership::tests`, 1 in `bridge::tests`).

Out of scope, captured in PR description: mention-spoofing as design
intent ("@-mention re-claims" matches the issue spec), restart drops
all claims (single-process MVP), real-dispatch integration test for
the gate's order-of-operations vs RBAC / journal / auto-reply.

`tokio::time::interval` defaults to `Burst` — if the sweep task is
paused past a tick deadline (long GC, suspended runtime, OS sleep),
the next `tick().await` returns immediately and `select!` keeps
draining backlogged ticks until the schedule catches up. Each
catch-up tick runs another `sweep_expired`, producing a burst of
near-zero-cost-but-noisy debug logs.

`sweep_expired` is idempotent so this isn't a correctness bug, but
`MissedTickBehavior::Delay` resets the schedule to a fresh 60s
cadence after a stall, which is closer to the intent ('sweep roughly
once a minute, not 'sweep N times in a row to make up for lost
time').