feat(join): tell apart the two ways of holding no invitation

[stormer78]

Follow-up to #351, applying the same rule to the row it left inconsistent. Single commit on main.

The observation

A VIC can only be issued to a persona DID that exists. So no persona implies no
invitation is possible; personas existing means one might exist.

That is provable, not a heuristic. validate_invitation_credential (in
openvtc-core/src/join.rs) requires credentialSubject.id — a credential
without one is refused — so there is no such thing as a bearer invitation, and
that subject is a persona DID.

What was wrong

"Use an invitation" showed one row for both situations: dim, reading "none held
for this community — paste one on the invitation step if you have one the vault
has not seen". A greyed-out row telling you there is a way to act on it, which
is the shape of confusion the routes list exists to remove — the same objection
that produced #351, left half-applied.

Now

No persona	Blocked — "an invitation is issued to one of your personas, and you have none yet"
A persona, none in the vault	FirstStep — "none is in your vault, so this starts by asking you to paste one — if you have none, the step offers to join without it"
One held	Ready
Community takes none	Blocked

A bug this caught in #351

RouteState::FirstStep carried only a note, and the take handler opened the
create-persona overlay for any route that announced a first step. That was
fine while the vetting route was the only one — and would have been wrong the
moment the invitation route announced one, which is this PR.

The invitation's first step is not an overlay; it is the page the route already
leads to. So FirstStep now carries FirstStepKind:

FirstStep { note: String, kind: FirstStepKind }

enum FirstStepKind {
    CreatePersona,  // the join does something first, then takes the route
    OnTheWay,       // nothing extra — the step is a page the route leads to
}

Inferring that from the route's identity would have put the same reasoning in
two places and got it wrong in one of them.

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 #351 in it.

• holding_no_invitation_is_shut_without_a_persona_and_a_step_with_one — both
  halves, in one test, so they cannot drift apart.
• the_two_first_steps_are_different_steps — pins the kinds, which is the
  assertion that would have caught the overlay bug above.