fix(channels): overlapping loadChannels() — an older response can overwrite the newer region's list #154

Summary

Overlapping loadChannels() calls can render the wrong region's channel list: the response that lands last wins, not the request that was made last. Pre-existing on master; found while reviewing #153 (it does not make it worse).

Reproduction (seen in a browser against a local server)

1. On #/channels, select region SJC and delay the /api/channels?region=SJC response by ~2.5 s.
2. Before it returns, switch to SFO.
3. The SFO response arrives first and renders; then the delayed SJC response arrives and replaces the list.
4. The region filter shows SFO, but the sidebar shows the SJC set.

Same on master and on #153.

Where (master e829d1ea)

loadChannels() in public/channels.js (around line 1856) has no request generation; every caller (RegionFilter.onChange around line 1014, the show-encrypted toggle, shared-channel approval, init()) awaits api('/channels' + qs) and writes channels unconditionally.

Proposed fix

A request token like the existing messageRequestId / beginMessageRequest() / isStaleMessageRequest() pattern (around lines 179–245): bump a channelsRequestId when loadChannels() starts, and drop the response (no render, no reconcile) if a newer request has started meanwhile. Keep it compatible with #153's client-state merge (sample the WS sequence for the request that actually renders).

Acceptance criteria

• Delayed older response + newer region change: the newer region's list is rendered and stays.
• No extra /channels request per change; existing callers unchanged.
• Unit test with controlled api() timing, plus a Playwright check with a delayed route.