Re-validate entries in PredicatedMap/PredicatedCollection readObject

[rootvector2]

PredicatedMap.readObject and PredicatedCollection.readObject rebuild the decorated map/collection straight from the stream and never re-run the predicate that the constructors apply to every element. A serialized form whose backing data was not produced through put/add (a tampered or hand-built stream) therefore deserializes into a decorator that holds elements its own predicate rejects. A PredicatedMap created with NotNullPredicate to forbid null keys, for instance, can be made to contain a null key, and code that trusts the decorator's guarantee then breaks.

I found this while checking the decorators' readObject paths against the invariant their constructors enforce (map.forEach(this::validate) / the per-element loop).

The fix re-validates each deserialized entry/element against the configured predicate and throws InvalidObjectException on a violation, mirroring the constructor. PredicatedSortedMap and the PredicatedList / PredicatedSet / PredicatedBag / PredicatedQueue / PredicatedMultiSet / PredicatedNavigableSet decorators inherit the check through these two base classes, so the whole predicated family is covered. The Transformed* decorators are intentionally left alone: their stored values are already transformed, so re-running the transformer on read would transform twice.

Existing serialized forms still load (the version-4 compatibility tests pass); only streams carrying predicate-violating data are now rejected.

Before you push a pull request, review this list:

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

Please see my comments.

[garydgregory]

Hello @rootvector2
Please see my comment.