fix(scripts): make the Postgres smoke report the code under test, not the environment

[eldonm]

scripts/smoke_postgres.sh reported failures three separate times this week that had nothing to do with Postgres, jvspatial, or jvagent. Each one cost real investigation before turning out to be the harness. Two commits, four defects, all in the script.

What went wrong, and why it was hard to see

1. It tested whichever jvagent was on PATH. Line 43 honoured $PYTHON for PYBIN, then invoked the bare jvagent console script. On a box with more than one install, the run exercised a different environment than the one you asked for. In practice jvagent resolved to an install whose jvspatial was an editable sibling checkout without asyncpg, so step 1 died with ImportError: asyncpg is required for the Postgres backend and the suite reported 8 failures across every later step. The interpreter is now derived from $PYTHON — $(dirname "$(command -v "$PYBIN")")/jvagent, falling back to "$PYBIN" -m jvagent — and ImportError was added to the bootstrap-failure grep so this specific cause names itself next time.

2. Two runs killed each other. Fixed container name, fixed ports, and pkill -f "jvagent $APP_ROOT" in the EXIT trap. An earlier run's cleanup terminated a later run's server mid-restart, producing server failed to restart, login failed post-restart, and a spurious 1 postgres/event-loop error in server logs — 3 failures, all pointing at the event-loop affinity code, none of them real. Container name and both ports are now per-run unique ($$-seeded, pick_port scans upward), and the server is tracked and torn down by PID.

3. APP_ROOT was cwd-relative and the app .env is gitignored. Run the script from a worktree and you silently get a keyless app. Now resolved from BASH_SOURCE; an explicit positional argument still overrides.

4. The turn check passed on non-empty, not on substantive. This is the one worth reading twice. With no usable model key the agent still answers — by echoing the prompt scaffolding it was handed:

agent: User message: Remember the number 8675309.

[Deliver every MANDATORY directive from the system prompt in full and in order, ...]

[ -n "$r1" ] was satisfied, turn produced a reply passed, TURNS stayed 1, and the run fell over two steps later at the recall check — with a failure that reads as "Postgres did not persist the interaction". The existing "no model key → skip" guard never fired, because there was a reply. reply_is_substantive() now rejects the scaffolding markers and a too-short reply, demotes the turn to SKIP naming the likely cause, and clears TURNS so the dependent checks skip with it.

Also: the workdir is now kept when any check fails, and its path printed. Previously the EXIT trap ran rm -rf "$WORKDIR" unconditionally, so a failure message pointed you at a bootstrap.log that had already been deleted.

Verification

Each run isolates one behaviour, all against merged main:

Run	Result
keyed app, explicit root, cwd=/tmp	15 passed, 0 failed, 0 skipped — incl. cross-restart recall from Postgres
keyless app (worktree), default root	12 passed, 0 failed, 2 skipped
keyless app, default root, cwd=/tmp	12 passed, 0 failed, 2 skipped
two runs launched simultaneously	ports 55983 / 56023, separate containers, both completed, neither killed the other

The last two are the point. Identical results inside and outside the repo, and zero failures where the same condition previously produced a misleading one — the keyless case used to report 14 passed, 1 failed.

--no-docker is unaffected: it requires JVSPATIAL_POSTGRES_DSN explicitly (the :? guard), so the now-dynamic PGPORT is never read on that path.

Gate: pre-commit run --all-files clean, pytest tests/ 3356 passed / 4 skipped.