Set up launch support path: Discussions, pinned thread, response SLA

[bordeauxred]

Why

If the newsletter feature lands well, traffic spikes within hours. Without a clear support path, every "how do I…" question becomes an issue, the issue tracker becomes noise, contributors hesitate to open real bugs, and the maintainer drowns in untriaged threads. Setting this up takes 15 minutes and prevents days of cleanup.

What

• Enable GitHub Discussions (Settings → Features → Discussions). Set up categories: `Q&A`, `Show and tell`, `Ideas`, `General`.
• Pin a "Newsletter launch — feedback & questions" Discussion so first-time visitors land somewhere intentional.
• Update issue templates (`.github/ISSUE_TEMPLATE/bug_report.md`, `feature_request.md`) to suggest Discussions for usage questions.
• Update `CONTRIBUTING.md` with a short "Getting help" section + a launch-week response-time note (e.g., 24–48h target during week of launch).
• Verify `SECURITY.md` is reachable and has a real contact (not a placeholder).
• Decide and document: do we triage from email, GitHub notifications, or a daily 5-min check?

Acceptance

• Discussions enabled, categories created, launch thread pinned.
• Issue templates suggest Discussions for usage questions.
• CONTRIBUTING.md states the response-time expectation.

Why this is launch-blocking

Codex review (2026-04-19) flagged this as a missing P0. For 100k engineers, the support path must exist before the link goes out, not after the first complaint arrives.