feat: allow form-level default error messages via options.errorMessages

[amds92]

Summary

Closes #69.

createHeadlessForm() had no way to set a message for a validation type (e.g. required) that applies to every field at once. The only override mechanism was per-field x-jsf-errorMessage, which meant repeating the same string on every property of a schema — painful for i18n and for schemas with many fields.

This adds options.errorMessages, a dictionary from validation type (required, type, minLength, ...) to a message string, applied to any field that doesn't already define its own x-jsf-errorMessage for that validation type.

createHeadlessForm(schema, {
  errorMessages: {
    required: 'This field is required.',
    minLength: 'This value is too short.',
  },
})

Precedence (most specific wins): field's own x-jsf-errorMessage > options.errorMessages > built-in default message.

One behavior worth a second pair of eyes: checkboxes get a special built-in required message ("Please acknowledge this field") instead of the generic one. options.errorMessages.required overrides that too, since it's the same validation type and applyCustomErrorMessages() doesn't special-case checkboxes. I think that's the right call (the option is about the validation type, not about how the default happens to be computed), but flagging it explicitly in case the intended behavior is different.

Test plan

Added to test/errors/messages.test.ts:

• Global message applied across fields of different input types
• Field-level x-jsf-errorMessage still wins over the global default
• Falls back to the built-in default when no override matches the validation type
• Covers type, enum, minLength validation types (not just required)
• Multiple validation types overridden at once
• Checkbox required special case
• Valid data produces no errors (no false positives)
• Nested/sub-object fields are covered
• Empty errorMessages: {} behaves like the option wasn't passed

pnpm test, pnpm lint, pnpm typecheck all pass locally.