Harden and feature-flag the Friend System rollout

## Goal

Ship the Friend System without turning user search, friend requests, notifications, or room invitations into new abuse, privacy, or operational failure modes.

## Security and privacy requirements

- Deny social reads/actions by default unless the authenticated relationship and resource state allow them.
- Enforce authorization server-side on every HTTP and Socket.IO action.
- Apply an explicit HTTP/Socket origin allowlist instead of reflecting arbitrary origins.
- Validate and size-limit social payloads and add per-user/per-pair rate limits for search, requests, blocks, notification actions, and invitations.
- A block must prevent new friend requests and invites, revoke pending social actions, and avoid revealing to the blocked user that a block exists.
- Never request, retain, search, log, analyze, or deliver through email; #191 is a hard launch prerequisite.
- Never log names, WCA IDs, access tokens, room passwords, notification contents, or friend graph edges.
- Do not expose online presence, hidden WCA identity, or private-room metadata outside the intended audience.

## Rollout and observability

- [ ] Gate server behavior and client entry points behind one documented `SOCIAL_FEATURES_ENABLED` rollout switch.
- [ ] Ensure the disabled state leaves existing room/timer behavior unchanged and provides a tested rollback path.
- [ ] Add privacy-safe metrics for request creation/acceptance, invite creation/join conversion, notification delivery/reconciliation failures, authorization failures, and rate-limit triggers.
- [ ] Add indexes/retention jobs before enabling writes and expose health/degraded signals for required social persistence paths.
- [ ] Test old-client/new-server and new-client/old-server behavior for the adjacent release window.
- [ ] Add abuse/authorization tests for ID tampering, blocked pairs, duplicate/replayed actions, unauthenticated access, disallowed origins, oversized payloads, rate limits, and email-like discovery input.
- [ ] Document data retention, account deletion behavior, incident rollback, and a short production verification checklist.
- [ ] Enable for a small test cohort/staging first, verify metrics and two-user flows, then enable broadly.

## Launch dependencies

- #191 stop requesting and purge WCA email
- #185 normalized username foundation
- #75 friendship lifecycle and blocking
- #82 discovery/public profiles
- #105 notification inbox
- #186 friends hub/presence
- #187 room invitations
- Complete the modernized production rollout in #176

## Non-goals

- Direct messages (#189).
- Browser push.
- Opt-in stranger matching (#190).

Es werden keine Dateien oder Test-Einstiegspunkte genannt. Beginne damit, das Serververhalten und die Client-Einstiegspunkte nachzuverfolgen, und prüfe anschließend die Startabhängigkeiten (#191, #185, #75, #82, #105, #186, #187 und #176); als abgeschlossen gilt die vollständige Umsetzung des Rollout-Schalters, des Rollback-Pfads, der datenschutzsicheren Observability, der Kompatibilitäts- und Missbrauchstests, der Dokumentation und der Checkliste für die stufenweise Aktivierung.

Vom Indexierungsmodell aus dem Issue-Text verfasst.