Redis-backed ephemeral systems

## Summary
Use Redis for ephemeral distributed systems that should not live purely in process memory.

## Scope
- Move appropriate ephemeral state into Redis, including candidates such as presence, typing, rate-limit counters, fanout helpers, and transient coordination.
- Define ownership boundaries between Postgres, in-process memory, and Redis.
- Keep product behavior correct across multiple BEAM processes and future multi-node deployment.
- Expose enough observability and failure handling for operators.

## Acceptance Criteria
- [ ] Ephemeral state that must survive process boundaries no longer depends on single-process memory.
- [ ] Redis-backed features degrade predictably if Redis is slow or unavailable.
- [ ] TTLs and cleanup behavior are explicit for each stored data class.
- [ ] The architecture keeps durable truth in Postgres and transient coordination in Redis.

## Operational Notes
- Self-hosted deployments need clear Redis sizing and failure expectations.
- This issue should avoid Redis creep for data that actually belongs in durable storage.