feat(join): create a persona without leaving the join

[stormer78]

Follow-up to #347, found in the same live guide run. Single commit on main.

Why

A community that vets is exactly where someone without a persona finds out they
need one — applying signs every card with it. The route was blocked with
"create one under My Identity", which meant leaving the flow, finding the
right pane, minting, and coming back to start the join again, entering the
community's DID a second time on the way. The requirements just read were gone
by then too.

What changed

n on that page opens the create-persona overlay over the join, with every
option it has: the label, whether the hosting server names the DID's path or the
operator does, and which context it is minted into.

It is the same overlay, not a second one. Its key handling and its rendering
were methods on the main page; they are now one module both pages call, taking
the overlay state and an action sender — the only two things they ever used from
self. The phases, the keys and the wording therefore cannot fork between the
two places it opens from.

Only the mint differs, and only in how it is run. The runtime loop spawns it
through its dispatcher; the join loop has none. So spawn_persona_mint splits:

• advance_persona_overlay — everything up to the mint. Phase-checking against
  config, no I/O. Returns the job when the last phase commits.
• the job itself — spawned by the runtime loop as before, awaited by the join
  loop, the way that loop already awaits the join sequence.

The join loop races it against the interrupt (R15) and drains its progress onto
the overlay as it arrives rather than after: minting a DID is not instant, and a
frozen "Creating persona…" is indistinguishable from a wedged one.

A persona minted here is usable when the overlay closes. It is persisted and
its listener started before then, because the route it unblocks is the one that
would otherwise fail on a persona that cannot send — which would be worse than
the block was. In State A there is no service to install into; that loop restarts
into the full pipeline after a join and brings it up there, as it already does.

The routes re-derive once the overlay is gone, so the row blocked on having
no persona unblocks itself rather than waiting for the join to be entered again.

The two places that said "create one under My Identity" now name the key on the
page they are printed on, and the footer offers N only where it is the thing
standing in the way.

Testing

• cargo fmt --all --check, cargo clippy --all-targets --all-features — clean
• cargo test --all-features -- --include-ignored — all green
• RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features — clean

Re-run after rebasing onto main with #347 in it.

applying_without_a_persona_points_at_the_key_here pins the blocked reason
naming n and not naming My Identity — the latter is the assertion that would
catch this regressing, since the sentence reads fine either way.

Not covered

The overlay's own behaviour is covered by the main page's existing tests, which
now exercise the shared module. What has no test is the join loop hosting it
— the inline mint, the progress drain and the listener start need a VTA, so they
are the part the live run has to prove. Worth knowing before this is relied on.

Not yet run against the live community; the guide run that prompted it is next.