#121 · Sanitize error_message persistence in daily_community_rollups

Context

apps/signal-bot/src/src/utils/community-rollup.ts:153-170 writes err.message verbatim into daily_community_rollups.error_message when the rollup generation fails. PostgreSQL/Outline errors can include connection strings, API tokens encoded in URLs, raw stack-trace fragments, or query plans — not appropriate to persist long-term in a DB column that any admin DB query exposes (and any future debug endpoint would render).

Same pattern likely exists in other persistence sites added during this onboarding work; audit and fix together.

Acceptance criteria

• [ ] Replace raw err.message writes in daily_community_rollups.error_message with a sanitized category + truncated detail
• [ ] Sanitization rules:
• Strip URL query strings (regex \?[^ ]+ → ?…)
• Strip anything matching Bearer [A-Za-z0-9._-]+ or glpat-[A-Za-z0-9._-]+ or other API-key patterns
• Truncate to 280 chars max
• Categorize: outline_4xx / outline_5xx / db_timeout / db_constraint / network / unknown
• [ ] Log full error to stderr only (already done; verify)
• [ ] Audit all other places this onboarding feature persists error strings (room_join_summaries.status is enum-only — fine; check community-rollup-scheduler.ts:84's admin-notify message also uses result.error — sanitize that too)
• [ ] Add a unit test asserting the sanitizer strips a representative bearer-token string

Technical hints

• A small helper in apps/signal-bot/src/src/utils/error-sanitize.ts exporting sanitizeError(err: unknown): { category: string; detail: string } would centralize this; reuse from anywhere else that persists errors
• The sanitized output should be safe to render in /admin queue UIs, Signal admin-channel notifications, and SQL WHERE error_message LIKE … filters

--- *S-tier (50 pts + 40 merge_pr = 90). Defensive fix; not exploited today but needed before any error display surface.*