fix(stream): release the JDBC result stream when it is destroyed

[LittleGnome]

Release the JDBC result stream when it is destroyed

Branch: fix/jdbc-result-stream-lifecycle

Three independent problems in ts-src/lib/jdbcstream.ts. They are grouped
because they are all about what happens to a result stream that does not end
the way the happy path assumes, and they overlap in the same twenty lines.

1. A destroyed stream leaks its connection

JdbcStream only closes the Java-side ResultStream from inside _read, on
the tick after close() has set the _closed flag. A consumer that stops
early never gets there, because no further _read arrives.

for await (const row of stream) {
  if (row.ID === wanted) break // connection never comes back
}

The same happens on stream.destroy() and when a later stage of a pipe()
chain errors. ResultStream.close() is what returns the connection to the
pool, so each occurrence permanently removes one connection. With
AS400JDBCConnectionPool there is nothing that reclaims it afterwards, and
once the pool is drained unrelated queries start blocking.

Fixed by implementing _destroy, which also covers being destroyed before
the queryAsStream promise has resolved.

Why the extra flag

ResultStream.close() returns its connection unconditionally, and
ResultStream.read() already calls close() at end of data. So a naive
_destroy would close a second time on the normal path — Node calls
_destroy after 'end' because autoDestroy defaults to true — and hand the
same connection to two callers.

A _jdbcStreamClosed flag now tracks whether the Java side still owns the
connection, and _destroy does nothing once it does not.

Follow-up worth considering: making ResultStream.close() idempotent on
the Java side would make this unnecessary and would also protect the one case
this patch deliberately leaves alone — a failure inside read()'s init
block, where the Java code has not closed but this patch assumes it has,
because double-returning a connection is worse than the leak that already
exists there today. Happy to send that as a separate PR; it needs a jar
rebuild, so it did not belong in this one.

2. An abandoned stream can terminate the process

_jdbcStreamPromise gets its rejection handler in _read. A stream that is
created and never read — the normal outcome when the query itself fails and
the caller never subscribes — leaves the rejection unhandled. On every Node
version this package supports (engines: >=16), the default policy for that
is to terminate the process.

The constructor now parks a no-op handler on the promise. The real handler in
_read is unchanged, so a consumer that does read still gets the error.

3. A close failure crashes consumers that already got their rows

A failing close() was reported with emit('error'). At that point every row
has been delivered and 'end' may already have fired, so consumers have
typically stopped listening for errors — and an 'error' with no listener is
an uncaught exception. A connection that could not be released turned into a
process-level failure.

It now goes to the Logger the library already has. baseConnection and
connection pass their logger in at the three construction sites; the default
stays the existing no-op logger, so nothing is printed unless a logger is
configured.

Tests

ts-src/unit-test/jdbcstream-spec.ts, 8 cases, using a fake Java stream that
counts close() calls. No JVM and no IBM i, so they run in CI.

Against the current implementation, 5 of the 8 fail:

✔ should read every chunk and end
✔ should not close the java stream again after it ended by itself
1) should close the java stream when a consumer destroys it early
2) should close the java stream when destroyed with an error
3) should close the java stream when destroyed before the promise resolved
4) should log rather than emit an error when close fails
5) should not leave an unhandled rejection when the stream is never read
✔ should still emit the rejection to a reading consumer

The three that already pass are there on purpose: they guard the behaviour
this change could plausibly break, in particular the double-close.

Verification

npm run build && npm test       -> 40 passing
npm run test-cjs                -> 40 passing
npm run lint                    -> clean
npm run format-verify           -> clean

No Java change, no jar rebuild, no new dependency, no public API change.