js: implement the Constraint Validation API subset this engine models

[tannevaled]

Summary

• setCustomValidity/.validity/.validationMessage/checkValidity were entirely missing.
• This engine models NO native constraints at all — no required/pattern/min/max/step checking against a value — so a custom validity message (dom.Node.CustomValidity, the same non-attribute runtime-field shape as round 138's Indeterminate) is the only thing that can ever make an element invalid. The ValidityState object's shape is spec-complete (all nine other flags present and always false) so a script reading any of them gets a real boolean, never undefined.
• checkValidity() fires a cancelable "invalid" event at the element when invalid, per spec.
• .willValidate deliberately left out: zero corpus usage found for it, unlike the four members above.
• Found by sweeping the same fresh github.com bundles round 138 came from, this time for method calls: github.com's own client-side form-validation UI (username/label/2FA-code fields) relies on this API extensively (setCustomValidity(msg)/setCustomValidity(""), reading .validity.customError/.validationMessage, gating on .checkValidity()).

Test plan

• New TestConstraintValidationAPI, git-stash-confirmed: reverting makes the test's own script throw TypeError: Cannot read property 'valid' of undefined.
• go build ./... && go vet ./... && go test ./... clean.
• Coverage floors held (css 99.5%, layout 100%, paint 100%, dom 98.4%, paginate 100%).
• Bench vs. real headless Chrome: flat/within already-documented noise across all ten pages, including github.com/golang/go itself (0.638, unchanged) — expected, pure JS-correctness fix with no paint-visible effect by design.

🤖 Generated with Claude Code