JS form-validation contracts

Form libraries own validity instead of the browser, and the same user-visible bugs the native Constraint Validation API produces reappear one layer up — just spelled mode, reValidateMode, setError, trigger, isValid, and resolver promises. They pass the happy path and surface only in real use: a form that flags every field before the user types, an error that persists after the field is corrected, a submit blocked with no visible message, a submit button stuck disabled forever, or an async/server error that lands on the wrong field or races a double click.

This skill is the library validity lifecycle. For the browser's own engine (:user-invalid timing, setCustomValidity, checkValidity/reportValidity) use constraint-validation-contracts; for the ARIA role/name/focus contract around errors use a11y-contract-testing; for the wording and localization of messages use i18n-copy-and-layout; for autocomplete tokens and auth-field specifics use frontend-auth-flow-contracts. Keep a11y, autocomplete/input-type, and wording observations as clearly-labelled secondary notes — they belong to those skills, not this one's contracts.