fix(sqlite3): report SQL errors on stderr and exit 1 without -bail (#338)

* fix(sqlite3): report SQL errors on stderr and exit 1 without -bail

A failed statement was appended to stdout as `Error: ...` and the command
exited 0 unless -bail was passed. Real sqlite3 writes the error to stderr and
exits 1 either way; -bail only decides whether the remaining statements run.

So `sqlite3 db "SELECT ..." > out.csv` wrote the error text into the data file,
and `sqlite3 db "..." && next` ran `next` after the query had failed. A caller
could only detect a bad query by opting into -bail, which also gave up the
later statements.

Errors now accumulate on stderr in statement order and the exit status is 1
whenever any statement failed. The two early returns that already wrote to
stderr prepend what the loop collected, so an error is no longer dropped when
formatting or writeback fails afterwards. Tracking the message on stderr as it
happens also removes the separate bail-error variable and its return branch:
the break plus the shared exit status covers it.

Successful runs, -bail's stop-at-first-failure behavior, the partial stdout
emitted before a failure, and writeback of a partially-successful script are
all unchanged.

* sqlite3: align row-limit test with stderr error reporting

The worker bridge surfaces a row-limit breach as an error result, so routing
SQL errors to stderr with exit 1 changes how this limit is reported too. The
test landed in #307 while this branch was open and asserts the prior behavior:
the notice appended to stdout with exit 0.

Reporting a truncated query as success is the bug this branch fixes, not a
case to preserve, so the expectation moves to stderr and exit 1 rather than
carving out an exception for limit errors in sqlite3.ts.