Problem

Under Oracle native network encryption, any server-side error crashed the connection instead of surfacing.

When a query hits a server error and out-of-band breaks are disabled (common behind firewalls and proxies, and the default on some servers), the server signals the error with an in-band break: marker packets, then the error in a data packet. The crypto-checksum keystream resets on a break, but that was never implemented, so the post-break error packet failed its integrity check and threw. The thrown error then tripped a preconditionFailure in readyForStatementReceived because errorHappened did not write the statement's .error state back.

Reproduced live against Oracle 23ai with SQLNET.ENCRYPTION_SERVER=REQUIRED + SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED and DISABLE_OOB=ON: every error query (missing table, syntax error, divide by zero, no-privilege view) crashed the process.

Fix

• Re-initialize the data-integrity keystream in both directions on the reset marker, and drop any partial packet, mirroring the reference thin drivers (go-ora HashAlgo.Init on reset). OracleNetworkAESHash/OracleNetworkRC4Hash keep their key generator and expose reinitialize(); the first derivation is unchanged, so existing behaviour and tests are unaffected.
• Write the statement state back in errorHappened so a pipeline error fails the statement and returns the connection to ready, instead of crashing. Matches the existing backendErrorReceived path.
• Throw, never trap, on a malformed or short native-encryption packet.

Verification

• Full battery on a single NNE-required connection: 27 queries, errors now surface the real ORA-00942 / 00936 / 01476 / 00904, 110k-row queries work before and after errors, 0 crashes. Same on the SHA1 (RC4) checksum path.
• 173 unit tests pass, including new tests for the keystream reset (positive and negative), decrypt hardening, the reset-marker action, and the error-then-ready no-crash path.