fix(#857): auth errors now say which field they are about

[TortoiseWolfe]

The bug

SignInForm and SignUpForm funnelled every error — including field-specific validation — into one form-level alert with no id, and no input carried aria-invalid or aria-describedby. A screen-reader user heard "Passwords do not match" with nothing saying which of the two password boxes to fix.

SignUpForm is the sharper case: three distinct conditions shared one string.

line	message	field it's really about
:59	"Invalid email address" / TLD error	email
:71	"Password must be at least 8 characters"	password
:77	"Passwords do not match"	confirm-password

So the fix isn't "add ARIA attributes" — it's to stop discarding which field the error belongs to. Both forms now carry a field-scoped error beside the form-level one, mirroring what ContactForm already does.

What deliberately stays form-level

The post-submit sign-in failure. That message is generic to avoid account enumeration; pinning it to the email input would both mislead and hint at which half of the credentials was wrong. Rate limiting and the captcha challenge aren't about one field either. There's a test asserting the sign-in failure does not mark email invalid.

The mismatch is announced against the confirmation box, not the password — that's the one the user is being asked to change.

Both tests I extended were stubs that asserted nothing

should have proper ARIA attributes in each accessibility file contained only example comments — rendering the form and asserting nothing, in the file whose job is accessibility. Two more instances of #396, found in passing.

The SignUpForm test is table-driven across all three conditions and checks the half that makes it worth having: the other two fields must stay clean. An implementation that marked every input invalid would satisfy "the error is associated" and still tell the user nothing.

Mutation-verified: routing the mismatch to password instead of confirmPassword fails exactly one case — "announces the mismatched confirmation against its own field".

Three things that cost me time

1. a@b is the load-bearing test value. type="email" accepts it, so native validation doesn't block submission, but validateEmail rejects it (needs a dot in the domain and a 2+ alpha TLD). A value the browser itself rejects never reaches React, and the test would assert against a form that never ran its own validation.
2. findByRole('alert') resolves to an empty live region on these forms, so the assertion reads Received: <empty> — the same trap that left accessibility.spec.ts:437 unable to see anything (Work queue: E2E tests that finish having run zero assertions (#396) — 6 auth-gated defects left #850). Follow the association instead.
3. getByLabelText(/^password/i) matches more than one control (the strength indicator contributes text). Selecting by id is unambiguous and is what the wiring refers to anyway.

I also asserted the message matched /email/i at first. It doesn't — for a@b it reads "Invalid or missing top-level domain (TLD)". It asserts non-emptiness now; pinning the copy would break on any wording change while proving nothing extra.

Scope and pre-commitment

ForgotPasswordForm:145 and ResetPasswordForm:97 have the identical shape and are not touched here — a follow-up, rather than silently widening this.

On #856: hand-rolling ContactForm's pattern here rather than adopting FormField is a vote to delete FormField. That's where the evidence already pointed — it has never rendered, and its help text is gated {helpText && !error}, hiding the hint exactly when it's needed. Say the word if you'd rather adopt and I'll revisit.

lint clean, 4733 vitest tests, tsc --noEmit clean.

Closes #857

🤖 Generated with Claude Code