Reject out-of-range sql date/time fields in DateTimeConverter.toDate

[rootvector2]

DateTimeConverter.toDate builds java.sql.Date/Time/Timestamp with valueOf, which silently rolls over out-of-range fields (2006-02-31 -> 2006-03-03, 25:70:90 -> 02:11:30, 2006-10-23 25:70:90 -> next day), so malformed input in the default useLocaleFormat=false path is accepted as a different value instead of rejected; found while auditing the sql converters against the strict setLenient(false)/ParsePosition check the same class already applies on its locale-format branch, and fixed by validating against strict JDBC-format DateTimeFormatters (ResolverStyle.STRICT) before valueOf, leaving valid padded and single-digit input unchanged.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hello @rootvector2

Thank you for the PR.

The Javadoc and exception messages should be updated, for example

String must be in JDBC format [yyyy-MM-dd] to create a ...

The behavioral contract has now become stricter: out-of-range fields are rejected instead of being rolled over. The error messages are unchanged. The Javadoc and messages are technically still true but it do not document the new
strictness. How about mention that "validation is strict, out-of-range fields are rejected”.

[rootvector2]

Makes sense. Updated all three exception messages to append "validation is strict, out-of-range fields are rejected" and added the same note to the toDate javadoc. Full mvn build still green (1287 tests, 0 failures).