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

apps/api/src/notify/index.ts と issue #82 から始めて、既存の notifier の契約とメールフローを理解してください。Slack の認証情報と配信動作を選択する前に、specs/api/saml.md と specs/behaviors/help-wanted-roles.md を読んでください。Slack DM の配信、ハンドルの解決、フォールバックまたは併用配信、SLACK_BOT_TOKEN の設定、および対応する失敗ログの実装が完了すれば、完了とします。

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