fix #461: add minlength breaking change detection

[dhananjay12]

Summary

Adds breaking change detection for minLength string property increases in OpenAPI schemas (following the same pattern as existing maxLength validation).

Breaking Change Logic

Context	Change	Breaking?	Reason
Request	minLength: 5 → minLength: 10	✅ Yes	Clients sending strings of length 5-9 will now fail validation
Request	minLength: 10 → minLength: 5	❌ No	Less restrictive - existing clients continue to work
Response	minLength: 5 → minLength: 10	✅ Yes	API contract now guarantees longer strings - may break client expectations
Response	minLength: 10 → minLength: 5	❌ No	API can return shorter strings - compatible change

New Incompatibility Properties

• incompatible.request.min.length.increased=true (enabled by default)
• incompatible.response.min.length.increased=true (enabled by default)

[ctreatma]

I think the breaking/non-breaking decision for minLength in responses may need to be switched. For responses, the concern is existing clients making decisions based on the old specification. If minLength is increased from 5 to 9 in a response, an existing client who is validating that minLength is 5 will still pass; on the other hand, if minLength is decreased from 9 to 5, an existing client who is validating that minLength is 9 will throw errors when the API responds with shorter strings.

Reusing the breaking change table from the issue description:

Context	Change	Breaking?	Reason
Request	minLength: 5 → minLength: 10	✅ Yes	Clients sending strings of length 5-9 will now fail validation
Request	minLength: 10 → minLength: 5	❌ No	Less restrictive - existing clients continue to work
Response	minLength: 5 → minLength: 10	❌ No	API contract now guarantees longer strings - will pass existing response validation based on old min length
Response	minLength: 10 → minLength: 5	✅ Yes	API can return shorter strings - will break existing validation that checks for strings of length at least 10

[dhananjay12]

I think the breaking/non-breaking decision for minLength in responses may need to be switched. For responses, the concern is existing clients making decisions based on the old specification. If minLength is increased from 5 to 9 in a response, an existing client who is validating that minLength is 5 will still pass; on the other hand, if minLength is decreased from 9 to 5, an existing client who is validating that minLength is 9 will throw errors when the API responds with shorter strings.

Reusing the breaking change table from the issue description:

Context Change Breaking? Reason
Request minLength: 5 → minLength: 10 ✅ Yes Clients sending strings of length 5-9 will now fail validation
Request minLength: 10 → minLength: 5 ❌ No Less restrictive - existing clients continue to work
Response minLength: 5 → minLength: 10 ❌ No API contract now guarantees longer strings - will pass existing response validation based on old min length
Response minLength: 10 → minLength: 5 ✅ Yes API can return shorter strings - will break existing validation that checks for strings of length at least 10

My thoughts were similar to exsisting logic of max_lenght in response and clients may have issues if they allocated buffers/UI for the minimum lenght (so a increase in min_lenght 5->10 would be breaking).
If the client is validating a min_lenght value, then it would be breaking anyways in either case. This is where consumer-driven contract testing comes in I guess where the focus is also how the clients use the response (even for optional fields).
Also, I have updated the PR to disable both he request/response for the minor release so shouldn't change any default behaviour now.