notifier: Slack DM channel (depends on deeper Slack integration)

从 apps/api/src/notify/index.ts 和 issue #82 开始，了解现有的 notifier contract 和电子邮件流程。在选择 Slack credential 和 delivery 行为之前，阅读 specs/api/saml.md 和 specs/behaviors/help-wanted-roles.md。完成的标准是实现 Slack DM delivery、handle resolution、fallback 或 combined delivery、SLACK_BOT_TOKEN 配置，以及相应的 failure logging。

Follow-up from #82

#82 wires up a real notifier for help-wanted-role events (interest expressed, role filled). The agreed-on first-cut shape is email-only via Resend — covered in that issue.

This issue tracks the Slack DM channel, deliberately deferred until we tackle deeper Slack integration.

Why deferred

The Notifier interface in apps/api/src/notify/index.ts already accepts maintainerSlackHandle per notification, so the data flow is ready. What's missing is the credential trust — sending a DM from a workspace bot requires either:

1. A workspace-installed Slack app with chat:write scope + a bot token (the easiest path).
2. SAML IdP-side identity assertions extended to support delegated Slack actions (much heavier).

We're already the SAML IdP for codeforphilly.slack.com (specs/api/saml.md), but that's an inbound SAML flow (user signs into Slack via us). Sending DMs out to Slack is the inverse — we'd be initiating a workspace action on a member's behalf. Cleaner to do that via a dedicated Slack app with its own token.

Scope (when picked up)

• Add a SlackDmNotifier implementation alongside EmailNotifier.
• A new env var (SLACK_BOT_TOKEN) — sealed-secret in the cluster repo.
• Map Slack handles → user IDs via users.lookupByEmail (or users.list cached) since handles can change. Skip if the handle doesn't resolve.
• Compound notifier: try Slack DM first, fall back to email if Slack delivery fails or the recipient has no Slack handle. (Or run both — pick when implementing.)
• Failure logging at the same envelope as today's notifier.

Related

• #82 — email-only first cut
• specs/behaviors/help-wanted-roles.md — what gets delivered