Performance work for large channels and history

## Summary
Improve performance for large channels, long histories, and heavier concurrency while preserving Discord-like user-visible behavior.

## Scope
- Reduce transcript, navigation, and permission-path costs for large channels.
- Introduce incremental history loading and UI strategies that stay smooth as message counts grow.
- Keep unread, mentions, and jump behavior correct under load.
- Establish explicit performance targets for realistic single-guild deployments.

## Acceptance Criteria
- [ ] Large channels remain usable without full-page stalls or runaway memory growth.
- [ ] History loading and navigation stay responsive as message counts grow.
- [ ] Benchmarking covers realistic authenticated LiveView/WebSocket flows, not only synthetic HTTP.
- [ ] Performance fixes do not regress correctness for permissions, unread state, or reconnect handling.

## Operational Notes
- Self-hosted deployments need clear capacity guidance and measurable targets.
- User-visible parity matters more than microbenchmark wins that distort product behavior.

Start by locating the transcript, navigation, permission, unread, mention, and reconnect paths, then establish benchmarks for authenticated LiveView/WebSocket flows with realistic message counts. Done means large channels avoid stalls and runaway memory, history navigation remains responsive, targets are documented, and permissions, unread state, and reconnect behavior remain correct.

Written by the indexing model from the issue text.