Reset PreparedStatement.maxRows on pooled statements

[toaditi]

Problem

EntityFindBuilder.makePreparedStatement() sets maxRows only when a positive value is requested, and never resets it otherwise:

if (maxRows != null && maxRows > 0) ps.setMaxRows(maxRows);   // never reset to 0

The default transaction manager caches prepared statements — TransactionInternalBitronix calls setPreparedStatementCacheSize(100). JDBC's maxRows is statement-level state that survives statement caching, so a PreparedStatement returned from the pool keeps the maxRows set by a prior find. A later find with the same SQL but no maxRows then inherits the stale limit:

• Silent truncation on most databases (e.g. a paginated find with maxRows=20 leaves 20 on the pooled statement; the next unbounded find with the same SQL returns at most 20 rows).
• Hard failure on H2, which requires fetchSize <= maxRows: the next find's default setFetchSize(100) throws Invalid value "100" for parameter "rows" because the stale maxRows is smaller.

Fix

Always call setMaxRows, using 0 (JDBC "no limit") when no positive value is requested — mirroring the always-set setFetchSize handling on the very next line, which already avoids this exact trap:

if (maxRows != null && maxRows > 0) { ps.setMaxRows(maxRows); } else { ps.setMaxRows(0); }

This is the only site that calls setMaxRows, and it is shared by the list/iterator and count paths, so the reset covers all finds.

Testing

Adds EntityFindTests > "maxRows does not leak onto pooled PreparedStatement", using the non-cached TestEntity so the finds actually build and execute a pooled statement: a first find with .maxRows(2) followed by an identical-SQL find with no maxRows must return the full result set. The test fails before the change (on H2, throws Invalid value "100" for parameter "rows" on the second find) and passes after. A full :framework:test run showed no regressions.

[toaditi]

Superseded by #737 (same change, opened from a personal fork).