fix(test): acknowledge sqlite3 statements instead of sleeping on them

[h4x0r]

row_history_oracle failed on CI with

panicked at core/tests/row_history_oracle.rs:48:5:
sqlite3 writer failed: Error: in prepare, no such table: t

then passed on re-run of the same commit, with no changes. Flaky by
construction, not by luck.

The race

Both gold-oracle fixtures hold a long-lived sqlite3 reader open (so the
-wal sidecar is retained) while separate short-lived writer processes mutate
the same database. Statements sent to the reader execute asynchronously in
that other process, and the fixture synchronised against them with wall
clock:

writeln!(rin, "PRAGMA journal_mode=WAL; … CREATE TABLE t(…);")
rin.flush()
std::thread::sleep(Duration::from_millis(400));   // the entire guarantee
…
writer_sql(bin, &db, "INSERT INTO t VALUES(1,'a'); …");

400 ms is a guess about how fast the host is. Lose the race and the writer
prepares against a table that does not exist yet.

The fix

HeldReader::run appends a unique sentinel to each statement and blocks until
it appears on the reader's stdout. sqlite3 executes a script strictly in
order on one connection, so the sentinel cannot print before the preceding
statements have run — the acknowledgement is a consequence of ordering, not of
timing. A 30 s timeout bounds it and panics with the offending SQL rather than
hanging forever. The sleeps are removed entirely, so the handshake is provably
what does the work.

Verification

Step	Result
Reproduce deterministically (sleeps → 0)	3/3 FAILED, the exact CI error
Handshake applied, sleeps deleted	green
15 consecutive runs	15 pass / 0 fail
Control A — remove the CREATE TABLE	FAILED loudly, no such table: t
Control B — sentinel that can never match	FAILED in 3.02 s, bounded, no hang
Restore	green

Control B matters as much as A: a handshake that hung on failure would trade a
flaky red for a 6-hour job timeout. Both mutations asserted their target text
was present before applying, so neither could silently no-op and report a green
that tested nothing.

Scope

wal_snapshot_oracle.rs carried the identical pattern and is fixed too — a
correction that does not reach its copies is barely a correction. Both files
now share core/tests/common/mod.rs.

Full suite: 542 passed, 0 failed (--no-fail-fast), cargo fmt --check
clean, clippy --all-targets -D warnings clean.

Incidental: row_history_oracle 0.83 s → 0.04 s, wal_snapshot_oracle
~0.9 s → 0.07 s. The 800 ms per fixture was pure waiting.

Deliberately separate from #10 (SQLCipher), which does not touch these files.