Sign-in's passkey lead and note draw §5's btn and muted text, and .passkey-lead, .passkey-note leave the markup #4301

Sign-in's passkey lead and note no longer use .passkey-lead or .passkey-note. The failing check, "the home carries no error-note…", should now pass, though I haven't seen the forge's run. Locally the type check, the design lint, and the sign-in page, home page, design-lint, passkey and claim-link tests pass. I did not run the whole suite or look at the page in a browser.

Cause of the failure: the passkey script is inlined on every page. My last commit put the literal error-note in it, so the home page carried that word and the home test caught it.

Fix: the script no longer names the class. The sign-in note carries data-fail="error-note", and the script toggles whatever class that attribute names. Only /signin now contains error-note. This is also a real use for a data attribute, unlike the earlier data-ceremony-note, which nothing read.

What changed (src/web/pages/site.ts, src/web/passkey-client.ts)

• The lead is a passkey-on stack stack-tight mb wrapper holding the primary large btn and a muted small break note with role="status".
• The password form, the sign-up link and the signup-mode sentence are untouched, and the form posts the same fields.
• A failed passkey sign-in adds error-note and role="alert" to the note and removes muted. "Cancelled." stays muted with role="status".
• test/signin-page.test.ts asserts the old class names are absent. It also runs the client script against a stub DOM to check both the failure and the cancel behaviour.

Left out

• The stylesheet rules and docs/DESIGN.md are untouched; part two removes them.
• Sign-up has no passkey lead in its markup, so it needed no change here.
• claim.ts, everyday.ts and first-admin.ts still use .passkey-note and are outside this issue. Their notes carry no data-fail, so the script leaves their styling alone.

To try it: open /signin in a browser with passkeys. Cancelling the prompt gives a quiet "Cancelled."; a server-side failure gives the red alert under the button.

Closes #4271

Sign-in's passkey lead and note no longer use .passkey-lead or .passkey-note. The failing check, "the home carries no error-note…", should now pass, though I haven't seen the forge's run. Locally the type check, the design lint, and the sign-in page, home page, design-lint, passkey and claim-link tests pass. I did not run the whole suite or look at the page in a browser.

Cause of the failure: the passkey script is inlined on every page. My last commit put the literal error-note in it, so the home page carried that word and the home test caught it.

Fix: the script no longer names the class. The sign-in note carries data-fail="error-note", and the script toggles whatever class that attribute names. Only /signin now contains error-note. This is also a real use for a data attribute, unlike the earlier data-ceremony-note, which nothing read.

What changed (src/web/pages/site.ts, src/web/passkey-client.ts)

• The lead is a passkey-on stack stack-tight mb wrapper holding the primary large btn and a muted small break note with role="status".
• The password form, the sign-up link and the signup-mode sentence are untouched, and the form posts the same fields.
• A failed passkey sign-in adds error-note and role="alert" to the note and removes muted. "Cancelled." stays muted with role="status".
• test/signin-page.test.ts asserts the old class names are absent. It also runs the client script against a stub DOM to check both the failure and the cancel behaviour.

Left out

• The stylesheet rules and docs/DESIGN.md are untouched; part two removes them.
• Sign-up has no passkey lead in its markup, so it needed no change here.
• claim.ts, everyday.ts and first-admin.ts still use .passkey-note and are outside this issue. Their notes carry no data-fail, so the script leaves their styling alone.

To try it: open /signin in a browser with passkeys. Cancelling the prompt gives a quiet "Cancelled."; a server-side failure gives the red alert under the button.