Fix client-side maxRows enforcement in ResultSet.next()

[gopalldb]

Summary

Add client-side maxRows enforcement in DatabricksResultSet.next(). When statement.setMaxRows() is set, next() returns false once the row limit is reached, even if the server returns more rows. Applies uniformly to all result types (Thrift, SEA, inline, CloudFetch).

Problem

The server-side row_limit/resultRowLimit is not always honored — the server may return more rows than requested. Some IExecutionResult implementations (LazyThriftResult, StreamingColumnarResult, StreamingInlineArrowResult) enforce maxRows internally, but InlineJsonResult and ArrowStreamResult do not, leaving a gap.

Fix

Single enforcement point at DatabricksResultSet.next():

• maxRowsLimit field cached from parentStatement.getMaxRows() at construction
• rowsReturned counter incremented on each successful next()
• Check maxRowsLimit > 0 && rowsReturned >= maxRowsLimit before delegating to executionResult.next()
• maxRows == 0 means no limit (JDBC convention)
• getUpdateCount() internal iteration bypasses the limit via countingUpdateRows flag

Existing per-implementation maxRows enforcement retained as defense-in-depth.

Test plan

• testNextRespectsMaxRows — limit=3, 4th next() returns false
• testNextMaxRowsZeroNoLimit — no truncation with limit=0
• testNextMaxRowsNullParentNoLimit — null parent = no limit
• testNextMaxRowsOneEdge — limit=1 edge case
• testNextMaxRowsDoesNotCallExecutionResultAfterLimit — verify no unnecessary delegation
• testNextMaxRowsWithEmptyResultSet — empty result + maxRows
• testNextMaxRowsGreaterThanActualRows — natural exhaustion before limit
• testNextMaxRowsIdempotenceAfterLimit — repeated calls after limit
• testGetUpdateCountBypassesMaxRows — DML counting unaffected
• Independent verification: 7/7 PASS (Agent C, black-box from spec)
• Full suite: 62 tests pass

This pull request was AI-assisted by Isaac.