Desktop create_channel can cross relay and identity during a community switch

[wesbillman]

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
• submit_signed_event_with_keys resolves the relay after awaiting admission
• apply_workspace mutates relay and keys separately
• open_dm shows the intended pinned relay + signer pattern and expected-context checks

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.