The first --apply run wrote all 764 rows, printed its summary, and then sat there. Thirteen minutes later the process was still alive. `connect()` returns a pooled singleton whose `disconnect()` is a no-op unless AC_DB_CLOSE=1 — deliberate, so serverless handlers reuse the pool, and database.mjs:118 already says scripts should call `closePool()` instead. This one only disconnected, so nothing ever closed the pool and the event loop stayed up. Now closes it in a `finally`, so it exits on the error path too, and uses `process.exitCode` rather than `process.exit(1)` so a failure cannot truncate output mid-flush. Dry run against production: exit 0 in one second. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>