Build the friend request, friendship, and blocking lifecycle

## Goal

Create the durable, server-authorized relationship model that every Friend System surface can depend on.

## Product contract

Authenticated users can:

- send a friend request;
- cancel their own outgoing request;
- accept or decline an incoming request;
- list accepted friends and incoming/outgoing requests;
- unfriend someone;
- block or unblock another user.

State transitions must be idempotent. A crossed request may become an accepted friendship instead of creating two requests. Self-requests, duplicate relationships, blocked pairs, and unauthorized transitions are rejected consistently.

Blocking is directional and overrides friendship state:

- blocking removes any accepted friendship between the pair;
- pending friend requests and room invitations between the pair become non-actionable;
- the blocked user cannot send new requests or invitations;
- APIs do not reveal whether a block exists.

## Data and API design

- Store one canonical relationship per unordered user pair using a normalized pair key and a unique index.
- Keep directional blocks separate from the symmetric friendship so future policy stays understandable.
- MongoDB remains the source of truth; add backward-compatible Prisma models and non-blocking PostgreSQL mirrors from the first enabled write.
- Notifications reference relationship/request resources but are not the relationship source of truth.
- Use authenticated REST operations for durable state changes; Socket.IO may announce changes to the affected users but must not own them.
- Return explicit public user projections. Never use, return, search, log, or retain email; #191 is a prerequisite.

## Acceptance criteria

- [ ] Document the relationship state machine, invariants, conflict responses, and any resend cooldown.
- [ ] Add MongoDB schemas/indexes and corresponding backward-compatible PostgreSQL migrations/mirrors.
- [ ] Implement authenticated list/create/cancel/accept/decline/unfriend/block/unblock operations.
- [ ] Enforce server-side authorization, per-user/per-pair limits, idempotency, and concurrency-safe unique-pair behavior.
- [ ] Emit typed realtime invalidation/update events to both users' existing per-user rooms.
- [ ] Reconcile state from REST after reconnect so missed realtime events do not corrupt the UI.
- [ ] Add tests for crossed requests, duplicate/replayed actions, concurrent accepts, self-actions, blocking, unblocking, unfriending, ID tampering, and disabled PostgreSQL.
- [ ] Add privacy-safe metrics for request/accept/decline/block outcomes without recording graph edges or identity.

## Dependencies

- #191 stop retaining WCA email addresses

## Launch gate

- #188 hardening must pass before broad enablement; it does not block building this foundation.

## Non-goals

- Direct messages (#189).
- Stranger recommendations or matching (#190).
- Browser push notifications.
- Room invitations (#187), which consume this relationship API.