[BalusC]

Fixes #69

A single criteria value on a field nested in a @OneToMany was built as a JOIN on the main query. On EclipseLink and OpenJPA this returned an entity once per matching element, so a page held fewer distinct entities than its limit, and an entity could show up on two pages.

• BaseEntityService now builds such a criteria as correlated subquery via buildArrayPredicate() in the data query, the same as multiple values. In the count query the JOIN stays, as it is inside the subquery selecting the entities to count. A negated value is always built as correlated subquery, because a negated JOIN matches any other element instead of no element. On OpenJPA a negated value is skipped in the count query, the same as multiple values, so the count may be too high there.
• The query is now DISTINCT only when it has a JOIN or fetch JOIN over a collection (hasCollectionJoins()). Fetches postponed by PostponedFetchRoot are not part of the query, so they no longer make it DISTINCT. This also matters for getPage() ignores ordering on a @OneToMany which is not fetched when PostponedFetchRoot is used #61, as a DISTINCT query cannot be ordered by an expression which is not selected.
• Within the correlated subquery, each item is built directly on the element via the new buildElementPredicate(), for a @OneToMany and an @ElementCollection alike.

New tests in OmniPersistenceIT:

• testSingleCriteriaOnOneToManyReturnsEachEntityOnce: two pages with phones.number like "1", with and without fetch, plus the count. On the code before this PR this fails on EclipseLink with 8 distinct of 20 persons.
• testNegatedSingleCriteriaOnOneToManyMatchesEntitiesWithoutMatchingElement.
• testSingleEntityCriteriaOnOneToMany.

🤖 Generated with Claude Opus 5.5