Close stdin for the CI steps that run the engine

linux-aarch64-gnu failed on JooqIT.insertAndSelect with "Code: 48. Processing
async inserts with both inlined and external data (from stdin or infile) is
not supported", and passed on the other run of the same commit. Not flaky in
the usual sense -- deterministic given one input nobody was looking at.

chDB embeds clickhouse-local, and ClientBase asks three times whether the
process's own stdin holds external data for an INSERT:

    !is_interactive && !stdin_is_a_tty && isStdinNotEmptyAndValid(*std_in)

A GitHub runner's stdin is not a TTY and sometimes has bytes in it. Then an
INSERT with inlined VALUES has, as far as the engine is concerned, two sources
of data, and it refuses. Reproducible on demand:

    printf '(9999)\n' | java ... "INSERT INTO t VALUES (1), (2)"   ->  Code 48
                        java ... < /dev/null                       ->  ok

So the CI steps that run the engine now close stdin. Four of them: the
integration suite, the packaged-JAR run and the consumer check (both run
QuickStart, which inserts), and UBSan over the whole suite. The AlmaLinux 8
step needs nothing -- `docker run` without -i already has no stdin.

This is CI hygiene, not a fix, and the comment in the workflow says so. The
hazard is real for any application embedding chDB whose stdin is a pipe with
data, and it is not ours to paper over in the driver.

Two things worth recording about why nothing else changed here.

async_insert defaulting to true is not chDB's doing. Upstream
clickhouse-server:26.7.3 reports async_insert=1 changed=0 as well -- the same
default, picked up correctly when chdb-core synced v26.3.9.8. What is
chDB-specific is only that a library embedded in someone else's process
inherits clickhouse-local's view of stdin. chdb-core already has an
is_background flag for the embedded case; these three checks do not consult it.

And passing --async_insert=0 from the driver, which is where I started, is
worse than the problem. It takes the same stdin and feeds it to the INSERT:

    stdin "(9999)", async_insert=0:  INSERT INTO t VALUES (1), (2) returns ok
                                     and the table holds [1, 2, 9999]

Silent rows the application never wrote, against a loud refusal today. The
Code 48 error is the engine declining to guess between two data sources, and
it is protecting the caller. Measured for completeness before discarding the
idea: 300 sequential inserts 430ms against 423ms, 8 threads x 150 inserts
1123ms against 1047ms -- no throughput argument either way, because
wait_for_async_insert is true and the caller waits regardless.

Also corrected a stale comment in the sanitizer step: chdb_jni_test has not
parsed Arrow formats since that path was deleted.

178 unit + 176 integration green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: ShawnChen-Sirius

.github/workflows/build.yml

@@ -178,6 +178,16 @@ jobs:
       - name: Integration tests on Java 11, 17, 21 and 25
         run: |
           set -eu
+          # stdin closed for everything below. chDB embeds clickhouse-local, whose
+          # ClientBase treats the process's own stdin as external data for an INSERT when it
+          # is not a TTY and has bytes available (src/Client/ClientBase.cpp). A runner's stdin
+          # sometimes does, and then "INSERT ... VALUES" fails with "Processing async inserts
+          # with both inlined and external data". Reproducible on demand:
+          #   printf '(9999)\n' | java ... "INSERT INTO t VALUES (1)"
+          # This closes it for our own test processes. It is not a fix -- the hazard is real
+          # for any application embedding chDB whose stdin is a pipe with data.
+          exec </dev/null
+
           case "${{ matrix.platform }}" in
             macos-*) OS=macos ;;
             *)       OS=linux ;;
@@ -237,6 +247,9 @@ jobs:
         # The production path: unpack into a content-addressed cache, verify the checksums,
         # load. Exercised separately because the integration tests use chdb.library.path.
         run: |
+          # See the note on the integration-test step: chDB reads the process's stdin as
+          # external data for an INSERT, and QuickStart inserts.
+          exec </dev/null
           mvn $MAVEN_ARGS -pl chdb-examples -am compile
           # Globbed rather than spelled out: the driver JAR carries the project version, which
           # moves with the engine baseline, and a hardcoded name here goes stale silently.
@@ -259,7 +272,9 @@ jobs:
         # outside this checkout with its own empty local repository. Run here, on every platform,
         # so that the answer does not go stale between releases; the one thing it cannot cover is
         # a real network transfer, which only Central can.
-        run: scripts/verify-consumer.sh ${{ matrix.platform }}
+        # stdin closed: the consumer project runs QuickStart, which inserts. See the note on
+        # the integration-test step.
+        run: scripts/verify-consumer.sh ${{ matrix.platform }} </dev/null
 
       - name: Archive debug symbols
         # Kept out of the runtime JAR (they are several times its size) but needed to read a
@@ -417,14 +432,14 @@ jobs:
         run: scripts/fetch-libchdb.sh ${{ matrix.platform }} target/engine/${{ matrix.platform }}
 
       - name: ASan and UBSan over the shim's own logic
-        # chdb_jni_test: Arrow format parsing, the handle registry and the signal guard, with
-        # no JVM and no engine in the process, so ASan's allocator interception is safe.
+        # chdb_jni_test: the handle registry and the signal guard, with no JVM and no engine
+        # in the process, so ASan's allocator interception is safe.
         run: scripts/run-sanitizer-tests.sh ${{ matrix.platform }} address,undefined
 
       - name: UBSan over the whole JDBC suite
         # In a real JVM against the real engine. UBSan instruments arithmetic rather than
         # intercepting allocation, so unlike ASan it coexists with both.
-        run: scripts/run-sanitizer-tests.sh ${{ matrix.platform }} undefined
+        run: scripts/run-sanitizer-tests.sh ${{ matrix.platform }} undefined </dev/null
 
       - name: Archive sanitizer output
         if: failure()