Slack adapter

Slack is where most security teams already coordinate. Pushing the SOC alert to the operator's existing #soc-alerts channel (with the right block-kit layout) lands the alert in the same workflow that already gets pull-request reviews and incident updates. The alert isn't a new tool to learn; it's a familiar message in a familiar channel.

The block-kit formatting carries the signal's severity color, the connector + disposition, the truncated rationale, and a 'view in dashboard' link. Operators triage from Slack first, then click through to the dashboard for the full audit row. The Slack message is the front door; the dashboard is the deep dive.

The adapter pulls the webhook URL from the CredentialVault (AAD = `delivery:slack:webhook_url:<destination_id>`), constructs a block-kit payload with the signal's severity-colored header + body + footer, and POSTs to the webhook. Slack's response code + retry-after header are read and surfaced as the adapter's typed result.

Slack's rate limit on incoming webhooks is ~1 message/sec per webhook. The adapter respects the `Retry-After` response header; if Slack returns 429, the dispatcher schedules a retry at the recommended interval rather than fire-and-forget.

Shipped 2026-06-07 (verifier half): `cybercli.delivery.channels.slack_ack` module ships three primitives — `verify_slack_signature` (HMAC-SHA256 with 5-min replay window + constant-time compare), `parse_block_kit_interaction` (form-then-JSON decode), and `extract_ack_intent` (pulls signal_id + actor + response_url out of a `cybercli_ack` action). SlackConfig gained an optional `signing_secret` field. The HTTP endpoint that runs these in order on `POST /api/slack/interactions` + hands the resolved signal_id to AckLoopEngine ships in v1.x.

Known limit: one webhook per Slack destination. Slack's app-based OAuth (which would let the engine post to multiple channels via one install) is a v1.5 backlog item.