[magnusp]

Closes #47. Part of #54.

What changed

• LibsqlStatement.getResultSet() now hands out the current result set once. It throws SQLException("ResultSet already requested") when a result set was already requested, including the result returned by executeQuery. execute leaves the result available for one getResultSet call.
• LibsqlStatement.getMoreResults(int) keeps xerial's argument validation. KEEP_CURRENT_RESULT and CLOSE_ALL_RESULTS throw SQLFeatureNotSupportedException("Argument not supported: Statement.KEEP_CURRENT_RESULT or Statement.CLOSE_ALL_RESULTS"). Any other value except CLOSE_CURRENT_RESULT throws SQLException("Invalid argument").
• closeOnCompletion() and isCloseOnCompletion() throw SQLException("statement is closed") after close, matching xerial's wording and closed-state rule.
• execute, executeQuery, executeUpdate, and getConnection still work after close(), matching xerial.
• close() now cleans up the current result set and generated keys even if the statement was closed first, while remaining idempotent.
• Added class-level Javadoc documenting the lifecycle, and LibsqlStatementLifecycleTest with one behavior test per transition.

Contract decision

Parity with xerial 3.53.4.0 at the pinned tag (JDBC3Statement.java:163-167,378-386, JDBC4Statement.java:34-44):

Transition	Behavior
getResultSet() after executeQuery or a prior getResultSet	SQLException: ResultSet already requested
getResultSet() after execute	Returns the result once; the next call throws
getMoreResults(KEEP_CURRENT_RESULT) / getMoreResults(CLOSE_ALL_RESULTS)	SQLFeatureNotSupportedException naming both arguments
getMoreResults(CLOSE_CURRENT_RESULT)	Closes the result set, returns false
closeOnCompletion / isCloseOnCompletion after close	SQLException: statement is closed
Execute-style methods and getConnection after close	Still work

Parity callout: execute-after-close deliberately copies what is probably an xerial bug (JDBC3Statement.internalClose no-ops once the pointer is closed, then prepares again). It is kept because #54 makes parity the default and Hrana does not prevent it. A probe against org.xerial:sqlite-jdbc:3.53.4.0 confirmed that Statement.execute, Statement.executeQuery, Statement.executeUpdate, and getConnection work after close, while prepared-statement execution still throws.

Evidence

Failing before the fix, with the new test file added and production code unchanged:

$ ./mvnw -q -pl libsql-jdbc -am -Dtest=LibsqlStatementLifecycleTest -Dsurefire.failIfNoSpecifiedTests=false test
[ERROR] Tests run: 8, Failures: 5, Errors: 1, Skipped: 0
[ERROR]   closeOnCompletionAndIsCloseOnCompletionThrowAfterClose:104 Expecting code to raise a throwable.
[ERROR]   getMoreResultsRejectsCloseAllResults:78 Expecting code to raise a throwable.
[ERROR]   getMoreResultsRejectsKeepCurrentResult:65 Expecting code to raise a throwable.
[ERROR]   getResultSetAfterExecuteQueryThrowsResultSetAlreadyRequested:34 Expecting code to raise a throwable.
[ERROR]   getResultSetAfterExecuteReturnsTheResultOnceThenThrows:52 Expecting code to raise a throwable.
[ERROR]   executeAndGetConnectionStillWorkAfterClose:119 » SQL Statement is closed

Passing after the fix:

$ ./mvnw -pl libsql-jdbc -am test
[INFO] Tests run: 156, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

Formatting:

$ ./mvnw spotless:apply
[INFO] BUILD SUCCESS

A direct probe of the published xerial 3.53.4.0 jar reproduced the pinned messages: ResultSet already requested, the KEEP_CURRENT_RESULT/CLOSE_ALL_RESULTS SQLFeatureNotSupportedException message, statement is closed for the completion properties, successful execute/getConnection after close, and prepared execution failing after close.

Deviations

None from xerial for the transitions in scope.