Desktop: channel sections of one community are published into another community's relay after a workspace switch

## Problem

Desktop persists and publishes the channel-sections layout of the **previously active** community into the **newly active** community after a workspace switch. The result is a sidebar in community A that shows section entries for channels that exist only on community B's relay.

This is the desktop counterpart of #5762 (mobile section folders bleeding across linked workspaces), and it is a persistence/publish bug, not only a render bug: the wrong assignment map is written to the other community's relay as a `kind:30078` `d=channel-sections` event, so it survives restarts and would follow the user to a new machine.

## Setup

- Desktop 0.5.20, macOS.
- Two self-hosted relays, community A and community B, separate deployments, separate databases.
- **Same identity (one pubkey) owns both communities.** That appears to be the precondition: the local stores are keyed `…::` and are individually correct, but the in-memory section state is not reset on switch.

## Observed

Community A's live `channel-sections` event and the matching localStorage key
`buzz-channel-sections.v1::` contain **7 channel UUIDs that exist only on relay B**, plus the two section objects (identical section UUIDs) that were created in B.

Verified in both relay databases: no channel row, no event and no message crossed over. `channels` and `events` are correctly partitioned by `community_id` on each relay. Only the NIP-78 section payload is mixed.

## Timeline (UTC, from both relays' `events` tables)

| Time | Relay | `kind:30078` writes |
|---|---|---|
| 19:30 | B | the 7 channels are created |
| 19:53:23 – 19:55:05 | B | 12 × `d=channel-sections` — user organizes B's sidebar |
| 19:55:25 – 19:56:29 | **A** | 5 × `d=channel-sections` — same layout, now written to A |

No user action took place in A in that window. The last write to A supersedes A's own pre-existing layout (from 13 hours earlier, before B existed), and A has served the mixed payload ever since.

## Expected

1. Reset or re-scope the section state when the active workspace changes; do not carry the previous workspace's assignment map into the next one.
2. Filter `assignments` to channels of the active community before persisting to localStorage and before publishing the `kind:30078` event.
3. When rendering, ignore assignments whose channel id is not in the active community's channel list, so a stale payload cannot resurrect the symptom.
4. Regression test: organize sections in B, switch to A, assert that the event published to A contains no channel id from B.

## Related

- #5762 — same class, mobile
- #6363 — `create_channel` can cross relay and identity during a community switch
- #5498, #5128 — other state that is keyed by identity rather than identity + community