Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@examples/fluss/run-demo.sh`:
- Around line 66-76: The hard-coded network name "fluss_iceberg_net" in the run
loop can break when Docker Compose uses a different project name; update the
script to avoid a fixed network string by either exporting a project name or
building the network name dynamically: set COMPOSE_PROJECT_NAME=fluss near the
top before bringing up compose, or replace occurrences of "fluss_iceberg_net"
with "${COMPOSE_PROJECT_NAME:-fluss}_iceberg_net" so the docker run line uses
the computed network name when running the DuckDB command (the DUCKDB_QUERY
usage in the docker run remains unchanged).

---

Nitpick comments:
In `@examples/fluss/run-demo.sh`:
- Around line 30-38: The script uses a fixed sleep after launching the tiering
job (docker compose exec -d jobmanager ./bin/flink run ...) which can let data
be inserted before the job is ready; replace the static sleep 5 with a readiness
loop that polls the Flink job status or jobmanager logs until the tiering job is
running (for example by repeatedly invoking a Flink CLI status command or
checking jobmanager logs for the job name) and only proceed when the job reports
RUNNING or a ready-ready log line; update run-demo.sh to perform this health
check before continuing with data insertion so the tiering job is guaranteed
initialized.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@examples/fluss/run-demo.sh`:
- Around line 5-7: The docker compose exec call can fail if the jobmanager
container hasn't started; replace the single-line `docker compose exec -T
jobmanager bash -c 'until curl -sf http://lakekeeper:8181/health > /dev/null
2>&1; do sleep 1; done'` with a guarded retry: first wait for the jobmanager
container to be reported as running (e.g., loop on `docker compose ps`/`docker
compose ps --filter status=running` and grep for jobmanager) and only then run
the curl loop with `docker compose exec`; implement this by adding an outer
`until` loop that checks container running status (or `docker compose ps -q
jobmanager` + inspect) and sleeps/retries, then run the existing inner
curl-until check once the container is up.
- Around line 83-85: The current parsing grabs the last numeric token from
docker/duckdb output (variables output/count), which can pull numbers from logs
or errors; change the pipeline to capture only the query result line and
validate it's purely numeric. Specifically, run the docker compose command the
same way (preserve 2>&1) into output, then replace the count extraction with
something like: extract the last non-empty line (e.g., using tail -n1) and
require it matches ^[0-9]+$ (e.g., via grep -E '^[0-9]+$') before assigning to
count so only a deterministic numeric query result from DUCKDB_QUERY is used in
the if check. Ensure you still redirect errors (2>&1) and keep the if condition
checking count as a numeric value.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@examples/fluss/run-demo.sh`:
- Around line 32-39: The detached Flink tiering start (docker compose exec ...
./bin/flink run ...) and the fixed sleeps (sleep 5 and the later sleep ~30) are
fragile; replace them with readiness checks that poll the Iceberg table until
data appears or a timeout elapses. After launching the job (the command starting
with "docker compose exec -d jobmanager ./bin/flink run" in run-demo.sh)
implement a loop that queries the Iceberg table (the same check used later
before DuckDB) at intervals, with a configurable timeout, and exit non-zero if
no rows are returned within the timeout; remove the fixed sleep lines and the
later blind 30s pause and use the same polling routine before running the DuckDB
query so the script deterministically fails on tiering timeout.
- Around line 6-7: Replace the unbounded readiness loops for "until docker
compose exec -T jobmanager true" and the inner "docker compose exec -T
jobmanager bash -c 'until curl -sf http://lakekeeper:8181/health ...'" with
bounded loops that fail after 120 seconds; implement by recording a start time,
polling until success or until elapsed > 120, and on timeout printing a clear
error message (e.g., "jobmanager did not become ready within 120s" / "lakekeeper
healthcheck failed within 120s") and exiting with non‑zero status; ensure both
readiness checks follow the same pattern so CI/demos stop deterministically on
failure.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@examples/fluss/run-demo.sh`:
- Around line 89-105: The current loop checks DuckDB output text for the string
"0 rows" (see the docker compose run --rm -T duckdb duckdb -c "$DUCKDB_QUERY"
invocation and the grep -q "0 rows" test), which is brittle; instead run a
deterministic COUNT(*) query and parse the numeric count to decide readiness.
Update the command that sets output to execute a SELECT COUNT(*) AS cnt FROM
(...) (or wrap $DUCKDB_QUERY) and then parse the returned number (e.g., with
awk/sed) rather than grepping for "0 rows", and use that numeric value in the
while loop to break when count > 0; keep the SECONDS timeout logic unchanged.
- Around line 5-12: The wait_for function currently uses eval "$@" which static
analysis flags; change wait_for to avoid eval by either (a) accepting the
command as separate args and executing them directly with "$@" (update callers
to pass commands/components without shell metacharacters), or (b) if callers
need shell parsing (pipes/redirections), accept a single command string and run
it explicitly with bash -c "$cmd" to make the intent explicit; update the
wait_for function signature and its callers accordingly (refer to the wait_for
function and all places invoking it).