Desktop create_channel can cross relay and identity during a community switch

Carl, an automated reviewer, commenting via Wes’s GitHub account.

## Problem

Desktop `create_channel` does not pin a coherent community context across its create and metadata-read transaction. A community switch while the Tauri command is suspended can mix the initiating workspace's signer with the newly active workspace's relay, then perform the metadata reread with another signer.

This was found while reviewing #6328, but it is **not caused by that PR**. The complete `create_channel` function is byte-identical at #6328's base (`9c2f05346`) and reviewed head (`2d0a384f4`). The relevant relay helper and workspace mutation behavior are also present on the base.

## Race

1. `create_channel` captures `creator_keys`.
2. `submit_event_with_keys` signs with those keys, but its downstream submit reads `relay_url_override` only after the rate-limit await.
3. `apply_workspace` can replace the relay override and signing keys under separate locks.
4. The A-signed create can therefore be posted to relay B.
5. The metadata reread calls `query_relay(&state)`, which resolves the then-current relay and signer again. It can query relay B as identity B for the A-created UUID.

Depending on timing and relay policy, the command can create a channel in the wrong community, return metadata under the wrong identity, or report failure after the create succeeded elsewhere. The pending-owner overlay is keyed to the captured signer, but that does not make the network transaction workspace-consistent.

## Source

At `2d0a384f4` (behavior is the same at base `9c2f05346`):

- [`create_channel` captures only keys, submits, then rereads through current state](https://github.com/block/buzz/blob/2d0a384f43b88dc630ea9449af3d5b1aeef64c46/desktop/src-tauri/src/commands/channels.rs#L304-L337)
- [`submit_signed_event_with_keys` resolves the relay after awaiting admission](https://github.com/block/buzz/blob/2d0a384f43b88dc630ea9449af3d5b1aeef64c46/desktop/src-tauri/src/relay.rs#L568-L581)
- [`apply_workspace` mutates relay and keys separately](https://github.com/block/buzz/blob/2d0a384f43b88dc630ea9449af3d5b1aeef64c46/desktop/src-tauri/src/commands/workspace.rs#L208-L225)
- [`open_dm` shows the intended pinned relay + signer pattern and expected-context checks](https://github.com/block/buzz/blob/2d0a384f43b88dc630ea9449af3d5b1aeef64c46/desktop/src-tauri/src/commands/dms.rs#L20-L71)

## Expected fix

- Capture or validate one coherent workspace context before the first await: relay scope, signer, and preferably the workspace/apply generation or frontend-provided expected relay and signer.
- Use that pinned relay and signer for both submission and metadata query (`submit_event_at_with_keys` / `query_relay_at_with_keys`, or an equivalent transaction helper).
- Fail closed or discard the stale result if the active workspace changes before returning/updating active UI state.
- Add a deterministic regression test that switches A to B between context capture and submit/re-fetch.

Read create_channel in desktop/src-tauri/src/commands/channels.rs, then compare submit_signed_event_with_keys in relay.rs and apply_workspace in workspace.rs with the pinned-context pattern in commands/dms.rs. Add a deterministic regression test that switches from workspace A to B between context capture and submit or refetch. Done means create and metadata reread use one coherent relay and signer, with stale workspace results rejected or discarded.

Written by the indexing model from the issue text.