The validation module already implemented the composable-rule idiom under
its own names (Check/Issue/SubjectContext) and a value-type Validator with
duplicated traversal machinery per layer. Renamed the core types to the
canonical names (Validation/ValidationError/ValidationErrorCollection/
ValidationContext/BuiltinValidation/AnyValidation), converted Validator to
a reference-type class with the two-tier default-rule split, and genericized
it over both Subject and Document via a new Traversable protocol so the
model and tagged layers share one walk engine instead of two copies. Wired
the JSON-representability rule set into the same shape and closed the two
missing pieces (unwrap combinator, JSON coverage/config-pin tests).
Move the validator toward the validation-rules idiom's identity-based
configuration. withoutValidating(_:) removes a rule by its description, the
removal identity the idiom uses, so descriptions must be unique and stable.
validationDescriptions lists the active rules in application order.
A configuration-pin test asserts the exact descriptions of the blank and
default validators and that the default descriptions are unique, so adding,
removing, or rewording a rule is a deliberate change that a test catches.
Both additions are non-breaking; the type-directed Validation<Subject>
dispatch and the error-rendering change remain the larger migration steps.
