Validate CSVFormat invariants when deserializing

[rootvector2]

CSVFormat.readObject restores the fields and reinitializes the transient writeLock, but it never calls validate(), so deserialization is the one path that builds a CSVFormat without the invariant checks the constructor runs. A crafted stream can therefore carry a state the Builder refuses, such as the quote character equal to the delimiter, QuoteMode.NONE with no escape character, or duplicate headers. I hit this while auditing the Serializable surface against the constructor's validate().

Call validate() in readObject once the fields are restored and rethrow its IllegalArgumentException as InvalidObjectException, so a hostile stream is rejected at read time instead of surviving as a broken format that later misparses input or throws from deep inside a print/parse callee. readObject is the only place that guards the deserialization path, since the Builder and constructor never see it.

• 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.