fix(schema): apply additive JSON Schema semantics to $ref sibling getters

[aqeelat]

Summary

OpenApiSchemaReference previously used reference-first fallback (Reference.X ?? Target?.X) for all keyword getters, which made additive assertion keywords look like overrides of the referenced schema.

Per JSON Schema 2020-12, assertion keywords alongside $ref are additive — both the sibling constraint and the target constraint apply. A sibling minProperties: 2 does not relax a target minProperties: 5.

This change revises the getter policy into three tiers based on feedback from @handrews in #2919.

Changes

Losslessly combinable scalars compute effective values:

Keyword	Logic
MinLength, MinItems, MinProperties	Math.Max(target, sibling)
MaxLength, MaxItems, MaxProperties	Math.Min(target, sibling)
ReadOnly, WriteOnly	true if either source is true
AdditionalPropertiesAllowed, UnevaluatedProperties	false if either source is false

Non-lossless keywords remain reference-first convenience accessors:

• Type, Format, Properties, Items, Required, OneOf/AnyOf/Not, If/Then/Else, etc.
• Maximum/Minimum/ExclusiveMaximum/ExclusiveMinimum — raw JSON number strings, not parsed to avoid precision loss
• Contains/MinContains/MaxContains — kept aligned as a group

Annotation keywords remain reference-first (unchanged):

• Description, Title, Default, Deprecated, Examples, Extensions, ContentEncoding, etc.

Serialization is unchanged: $ref siblings still round-trip on JsonSchemaReference.

Design rationale

• Non-lossless applicators (e.g. Properties, Items) cannot be collapsed into a single effective value without allOf composition. Target-preferred was considered but drops sibling constraints; reference-first keeps authored values visible and preserves setter/getter stability.
• Raw numeric string bounds (maximum/minimum) are stored as strings to preserve arbitrary JSON number precision. Parsing to decimal for comparison risks choosing the wrong stricter bound on high-precision values, so these stay reference-first.
• Required/AllOf merge attempts were reverted after review — mutable collection wrappers violated standard ISet/IList semantics (mutations disappeared). These stay reference-first.

Fixes #2919

[handrews]

I'm not entirely sure the additionalProperties and unevaluatedProperties behaviors are correct. Both of those have behavior that is highly dependent on their exact schema location. In particular, additionalProperties can only be evaluated in terms of its immediate adjacent keywords in the same schema object. And for unevaluatedProperties, the behavior of placing in in the $ref source vs target is very different. Based purely on the comments (I haven't had time to try to understand the code- this is not an ecosystem with which I am familiar) this also seems to treat both as booleans, when either could also be a non-trivial schema of some sort.