Decide whether 'violation' and 'error' both earn their keep in validation method names

[AlexSkrypnyk]

Summary

Methods that validate a value and return ?string (NULL meaning valid, a message meaning invalid) are split across two suffixes, *violation() and *error(), and both are consumed side by side inside Field. This was deliberately left out of #138, which converged several other naming conventions, because it is not clear that a rename is the right answer. The underlying question is whether the two suffixes draw a real distinction that is merely applied inconsistently, or whether one of them is redundant.

Details

The split

*violation() - 8 sites:

• src/Model/DateBounds.php:95 violation()
• src/Model/NumberBounds.php:75 violation()
• src/Model/SelectionBounds.php:85 violation()
• src/Model/FilePickerConstraints.php:121 violation()
• src/Model/FilePickerConstraints.php:149 pathViolation()
• src/Model/Field.php:532 requiredViolation()
• src/Model/Field.php:556 boundsViolation()
• src/Model/Field.php:570 pickerViolation()

*error() - 6 sites:

• src/Model/Template.php:288 error()
• src/Model/Template.php:320 partError()
• src/Model/Field.php:591 templateError()
• src/Model/Field.php:631 optionError()
• src/Model/Field.php:674 scalarOptionError()
• src/Model/Field.php:715 rankingError()

Why this is not a straightforward rename

1. A plausible hypothesis is that violation means "a constraint was breached" while error means "the value is malformed", but the evidence does not support it cleanly: both return the same ?string contract, and both are called from the same place.
2. The fragment-versus-sentence axis does not align with the split either. requiredViolation() returns a full sentence per its own docblock, while optionError() returns a fragment. The suffix therefore does not predict the shape of the returned message.
3. A third, unrelated use of the same suffix sits nearby: src/Engine/Engine.php:267 optionsError() returns an EngineException rather than a ?string, so the *Error suffix already carries two different contracts in the codebase.

Questions to settle before any rename

• Is there a real semantic distinction the two suffixes are meant to draw? If so, document it and move the misfiled methods onto the correct suffix.
• If there is no distinction, pick one suffix and converge on it.
• Either way, decide what the returned message shape should be (fragment or full sentence) and make it consistent, since that currently varies independently of the suffix.
• Consider renaming Engine::optionsError() regardless, since it returns an exception rather than a message and collides with the naming used for the ?string family.

Note

These are public methods on Model classes, so any rename is a public-API change.