feat(persona): create a standalone persona DID on demand

[stormer78]

Problem

Personas could only be minted as a side effect of joining a community (the "mint new identity" choice mid-join). There was no way to create a persona DID up front — which you need in order to receive a VIC (Verifiable Invitation Credential) bound to a pre-created persona DID (one that isn't your VTA DID), and then join cleanly on the join-as-subject path (no subject-linkage proof needed).

What this does

Adds a "create persona DID" action, reachable two ways (per request):

• Top-level menu — a new "Create Persona DID" item (an action item, like Quit).
• VTA panel — the n key, with n: new persona hints (including an empty-state hint when no personas exist yet).

Both open a centered overlay that:

1. Prompts for a label (⏎ create / esc cancel),
2. Runs the VTA mint, streaming progress (find server → create DID → save),
3. Shows the new did:webvh and copies it to the clipboard (c: copy again, ⏎/esc close) — or shows the error.

The minted persona is a standalone orphan, listed in the VTA panel's Context Identities and reusable in any later join (JoinIdentityChoice::Reuse). Hand its DID to a VTC, receive a VIC bound to it, then join on the clean join-as-subject path.

Implementation

• New state_handler/create_persona module owns the mint orchestration: pick a WebVH server → create_did_via_server → persist via the shared mint_persona_into (built from a scratch SetupState, so zero edits to that proven persist code). Runs inline-await, mirroring the join flow's mint sub-sequence minus the community/submit parts.
• A page-level overlay (MainPageState::create_persona, like the community switcher) with phases Label → Working → Done/Failed. Editing keys are forwarded to a tui_input::Input via an action (the main page uses the cloned-props pattern). The mint runs in the loop on CreatePersonaSubmit; the clipboard copy reuses clipboard.rs.

Note on a revised design decision

While investigating I found the join flow's pre-mint create_persona_keys / create_update_keys results are actually discarded — create_did_via_server requests signing_key_id: None / ka_key_id: None, so the WebVH server generates the keys. Rather than extract a "shared" helper that would either replicate that dead code or change the join hot path, I gave the standalone flow its own focused helper and left the join path untouched. Extracting a shared mint helper (and dropping the join's redundant key calls) is a sensible follow-up, tracked separately.

Limits

Same prerequisites as join: needs the always-on admin VTA session and a WebVH server advertised by the VTA (serverless mint still unsupported — surfaced as an error).

Tests

• Key-handler tests: both entry points (VTA n, menu Enter) and every overlay phase (label edit/submit/cancel, done copy/close, working swallows input).
• Reducer tests: overlay open / label edit / close; and that the mint + copy arms defer to the loop.
• cargo build, full cargo test (0 failures), and cargo clippy --all-targets all clean (only a pre-existing mod.rs:138 warning, untouched).