Fix NullPointerException in Firebird transaction isolation resolution

[thswlsqls]

Fixes #39133.

Changes proposed in this pull request:

• Guard FirebirdStartTransactionPacket.getIsolationLevel() with null != before reading the BOOLEAN-format CONCURRENCY and CONSISTENCY transaction parameter buffer flags, so an absent flag no longer triggers an unboxing NullPointerException.
• Align these two checks with the sibling guards already used for READ_COMMITTED, isAutoCommit, and isReadOnly, which all test null != on tpb.getValue(...).
• Rework assertIsolationLevelSerializable and assertIsolationLevelNone to build the packet through the real parseBuffer path instead of reflectively injecting a CONCURRENCY -> false entry that parseBuffer can never produce; the previous injection masked the NPE. Remove the now-unused reflective helper and its imports.
• Wire format is unchanged and the fix is backward compatible.

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.
• I have updated the Release Notes of the current development version. For more details, see Update Release Note

[terrymanu]

Summary

Review Result: Not Mergeable

Feedback Mode: Change Request

Reason: The explicit CONSISTENCY NPE path is fixed, but the linked issue’s no-isolation path now resolves to an unsupported isolation level.

Issues

• P1 — Omitted isolation is resolved as NONE instead of Firebird’s default CONCURRENCY
  • Problem: getIsolationLevel() returns TransactionIsolationLevel.NONE when the TPB contains no isolation item, and the updated test codifies that result. Firebird’s wire-protocol documentation delegates TPB semantics to the InterBase API documentation, which specifies that omitting the isolation mode means isc_tpb_concurrency. The executor stores the returned value in the session, and ProxyDatabaseConnectionManager later forwards JDBC TRANSACTION_NONE. The pinned Jaybird 5.0.10 mapper explicitly rejects that value.
  • Impact: A TPB without an explicit isolation flag avoids the original NPE but can still fail when the first backend connection is created, so the linked issue’s no-isolation scenario remains broken.
  • Required Change: Please resolve omitted isolation to Firebird’s default CONCURRENCY, represented by TransactionIsolationLevel.REPEATABLE_READ in the existing mapping, and update the direct regression test accordingly. The explicit CONSISTENCY case should remain SERIALIZABLE.

Review Details

• Review Focus: Code Correctness Review; CI not reviewed by request.
• Reviewed Scope: All three authoritative changed files: RELEASE-NOTES.md, FirebirdStartTransactionPacket.java, and FirebirdStartTransactionPacketTest.java; adjacent Firebird executor, session/JDBC propagation, and Jaybird 5.0.10 mapping were traced. Latest head: 5bd00f4c50bf72fe63c36a7ec629fbe8cbb362f2. PR metadata base: master at e249deba59d3583dc5464292672c5c73a92c2832; current fetched master: 25fa8a70da12ac6897d0af9880398a33c3021faf; local merge-base: af91b1c34cb041466449eec61ae711ec1f245d92. Both base positions produced the same three-file triple-dot scope, matching GitHub /pulls/39136/files.
• Not Reviewed Scope: GitHub Actions and other CI checks; live Proxy/Firebird E2E execution.
• Verification: ./mvnw -pl database/protocol/dialect/firebird -Dtest=FirebirdStartTransactionPacketTest -Djacoco.skip=true -DskipITs -B -ntp -T1C test exited 0 with 8 tests passing. A direct Jaybird 5.0.10 mapper probe confirmed that Connection.TRANSACTION_NONE throws IllegalArgumentException: Transaction isolation level 0 is not supported.
• Release Note / User Docs: The release-note entry is present and scoped appropriately. Additional user documentation is not required because this fix introduces no intended configuration, migration, or public API change.