Full `not` keyword support beyond enum/const (plus if/then/else)

[benjamineckstein]

Problem

The not keyword is only handled for the enum/const case today. A schema like { "not": { "enum": ["a", "b"] } } correctly emits a not_in:a,b rule. But every other shape of not is unvalidated:

• type-exclusion not, e.g. { "not": { "type": "string" } } (value must NOT be a string)
• nested-object not, e.g. { "not": { "required": ["x"], "properties": { ... } } }
• composed not, e.g. not wrapping an allOf/anyOf/oneOf

This also covers JSON Schema conditional schemas: if / then / else. None of these are translated into validation, so a payload the spec intends to reject is accepted.

Impact

Constraints expressed via not (other than enum/const) and via if/then/else are silently dropped. The generated rules() is more permissive than the spec, so spec-invalid payloads pass validation. This is a correctness gap, not just a missing nicety.

What correct support looks like

• type-exclusion not maps to a rule that rejects the excluded type(s)
• composed/nested not is either translated faithfully or, where Laravel's rule set cannot express it, surfaced via a custom rule
• if/then/else is translated into conditional validation (e.g. required_if / exclude_if families or a custom rule) so the dependent constraints apply
• anything genuinely inexpressible stays recorded in the fidelity report rather than silently dropped

Current behavior (recorded in fidelity report)

These constructs are recorded in openapi-laravel.unsupported.json (the drift-checked fidelity report) as correctness-affecting constructs the generator cannot faithfully represent. Only enum/const not is implemented today (not_in).