Desktop identity tests race on the shared test_support::PAYLOAD global

[muscariello]

Three tests in commands::identity::tests share one process-wide static and can clobber each other under parallel execution.

Seen once in a normal cargo test run:

---- commands::identity::tests::an_rsa_only_account_reports_what_it_published stdout ----
panicked at apps/shadi_desktop/src-tauri/src/commands/identity.rs:709:9:
must name the algorithm: @msardara: auth configuration error:
no ssh-ed25519 key published (found: none)

It expected found: ssh-rsa — the payload it had just set. It read someone else's.

Cause

test_support (identity.rs:658) holds one static PAYLOAD: OnceLock<Mutex<Option<String>>> for the whole test binary. Three tests write it and then read it back through published_keys():

• identity.rs:706 — an_rsa_only_account_reports_what_it_published (sets ssh-rsa …)
• identity.rs:794 — sets a generated key line
• identity.rs:803 — sets an empty string, which is what produces found: none

Nothing serialises set-then-read, so any interleaving where one test's set lands between another's set and its read fails the reader. The mutex protects each access but not the pair.

Reproduction

Intermittent, and rare: it failed once, then passed 35/35 single-threaded and across 5 consecutive parallel runs. CI has not hit it yet.

Fix options

• A test-local mutex held across set-and-read, so the three serialise against each other
• Or drop the global: thread the payload through fetch_github_human_did as a parameter, which removes the shared state instead of guarding it

Same category as #204 — a latent shared-state race that parallel execution exposes and --test-threads=1 hides.