Multi-statement SQL (;-separated) silently executes only the first statement

## Summary
A `sql` operation containing multiple `;`-separated statements runs **only the first** and silently drops the rest — no error, no atomicity, no cross-statement visibility.

- `INSERT …; UPDATE …` → applies only the INSERT (UPDATE dropped, `n` stays 1).
- `INSERT …; INSERT INTO NoSuchTable …` → the first INSERT persists despite the doomed second statement (which would otherwise error).

So it is not a batch/transaction: callers that expect multi-statement or batch semantics get partial application with no signal.

## Suggestion
Either reject multi-statement input with a clear error, or support it as an atomic batch; at minimum document that the `sql` op is single-statement.

## Related
The same scenario also reproduced an SQL `UPDATE n = n + 1` lost-update under concurrency **on LMDB** (RocksDB serializes correctly; `addTo` is correct on both). That is the known LMDB/`ifVersion` same-key non-serialization family (see #1288) extended to the SQL write path — SQL arithmetic UPDATE is not an atomic merge. Folded there, not filed separately; for concurrent counters use `addTo`, not `UPDATE col = col + n`.

## Repro
`integrationTests/qa-scratch/sql-concurrency.test.ts`

---
_Found via the exploratory QA campaign (qa-explorer), scenario QA-051. Harper `001bf7b9c` (v5.1.0, main)._