Multi-channel access (Slack, Matrix) reusing access pair shape

[kortiene]

Context

claw access pair telegram <agent> works end-to-end (B9, validated v0.2). The architecture was designed to be channel-agnostic: token issuance, hash-only persistence, audit chain, and local-socket handshake are all in src/claw/telegram/pairing.py but should generalize.

v0.3 should extract the shared core and add a second channel (Slack or Matrix) without copy-pasting the pairing logic.

Source: docs/SPRINT_PLAN.md §8.

Acceptance criteria

• Refactor: extract pairing.py and store.py channel-agnostic surface into src/claw/access/ package; telegram/ becomes a channel adapter.
• Channel adapter interface: name, serve(config) -> None, parse_pair_payload(payload) -> AgentToken | None, format_pair_url(agent, token) -> str.
• Add Slack adapter (preferred — same socket-mode polling shape as PTB) at src/claw/access/slack/. Bot replies to a /help slash command, a /status slash command, and a pair-<agent>-<token> payload via DM.
• OR add Matrix adapter (alternative if Slack auth flow is too heavy) — same surface.
• claw access pair slack <agent> / claw access serve slack work analogously to telegram.
• Audit events: slack_pairing_initiated, etc., reusing the same schema as telegram.
• All existing telegram tests still pass; new tests mirror the telegram suite for the new adapter.

Out of scope

• Both Slack AND Matrix in v0.3 — pick one and ship it well.
• Channel-to-channel forwarding (/ask from Slack -> agent -> reply on Slack while also notifying Telegram).

References

• docs/SPRINT_PLAN.md §8
• src/claw/telegram/pairing.py, store.py, bot.py
• Session 4 + 6 HANDOVER for the live-validated architecture