Ask for one name, because that is all it ever was

[NiKrause]

Ready. The release this waited for exists: the handle is 64 random bytes from 0.5.1, which reached main separately as #87. The pin here is 0.5.1 and this branch is rebased onto current main.

Worth recording, because it cost a wrong conclusion once: 0.5.1 was published to npm without a GitHub release, so the release list still ends at v0.5.0 — dated a day before #46 was merged. Checking releases says the blocker is still there.

The onboarding screen asked twice for a label and warned that sharing the first one would destroy somebody's passkey. Both follow from the same defect: the identity provider built the WebAuthn user handle out of that field, and an authenticator replaces a credential whose (origin, handle) already exists. The field was an identifier wearing a label's clothes, and warning about it was the honest thing to do.

The handle is 64 random bytes now, which makes the field a name and nothing else. The code comment above the form has been waiting for exactly this:

…it stays until the handle is random rather than typed — #45, after which this field is genuinely just a name and the two can become one.

What changes

• One input. Its value goes to WebAuthn as both the account name and the display name — two slots in the same credential picker, not two facts about a person.
• The warning goes, in both catalogues: "If somebody on this device has already used the same name, pick another: theirs would be replaced." Two people at one front desk may now enter the same name and get two identities.
• The rest of the hint stays — no e-mail needed — and gains the reason the name is harmless.
• onboarding_display_name and its hint are deleted from en.json and de.json rather than left dangling; nothing else referenced them.
• m0-shell keeps its assertion that the hint is tied to the input via aria-describedby. A hint a screen reader never reaches is not a hint, whatever it says — only the reason it exists has changed.

Related

fix/accounts-per-passkey builds account switching on this device — the follow-on consequence of the same change, since re-registering now adds a passkey instead of replacing one. It does not touch StudioGate.svelte, so there is no overlap in the diff, but the two belong together: this PR removes the warning that the absence of account switching would otherwise justify.

Verification

Build succeeds, 180 unit tests pass, prettier and eslint clean. The E2E onboarding helpers now fill one field; they were not run here.

Added after the rebase

Sitting next to the account separation (#82), two texts on one screen contradicted each other. The onboarding warning ended "whatever sits under the old passkey is out of reach", while the footer three lines below offers "switch account — sign in with a different passkey on this device".

Since accounts are separated per DID rather than overwriting one another, it is the warning that was wrong: a second passkey leaves the first account's studio exactly where it was, and switching leads back to it.

What survived is the part still worth saying — the studio sees a new device and has to approve it again. That is a real cost and a real reason to press the other button; losing the data is not one any more. Both catalogues and the comment above the paragraph moved together.

Verification after the rebase

Build, prettier, eslint, svelte-check (0 errors) and 188 unit tests green locally, plus m0-shell and m2-accounts — both sides of the contradiction. CI green on 410d179.