[luthermonson]

Bumps the exact Turso pin from =0.7.2 to =0.8.2, the latest stable release (ephpm/ephpm#535). The ePHPm side follows in a separate PR that points its litewire rev at this branch. Do not merge without review: Turso is the database engine, and clustered CDC in ePHPm is experimental.

What changed

• Cargo.toml: pin bumped, with a comment listing what the bump changes. Cargo.lock: the nine turso* crates move to 0.8.2, and antithesis_sdk moves from 0.2.9 to 0.3.0.
• No litewire source change was needed.
• New test journal_mode_change_on_a_capturing_connection_is_refused (crates/litewire-turso/tests/cdc_replication.rs). It fails on 0.7.2 and passes on 0.8.2.
• Docs: README, CONTRIBUTING, docs/architecture.md, the litewire-turso crate docs and CHANGELOG now give the new pin.

Upstream changes from 0.7.2 to 0.8.2 that matter here

I diffed the turso and turso_core crate sources and read the 0.8.0 changelog. 0.8.1 and 0.8.2 contain only CI changes.

1. journal_mode is refused while CDC capture is on. Turso only supports wal and mvcc; other modes are silent no-ops. On 0.7.2, a capturing connection accepted a switch from WAL to MVCC, and per upstream, capture then stopped silently while the pragma still reported it as on. Writes after that would not replicate. 0.8.0 returns cannot change journal_mode (...) while CDC capture is active. This is a fix.
2. The Rust binding now has a per-connection operation gate.
   • Connection::execute_batch and the new batch / transactional_batch take the connection exclusively.
   • While a Rows from the same connection (or a clone of it) is still being read, they fail with Misuse("connection is busy with another operation").
   • A query or execute that starts during a batch fails with connection is busy executing a batch.
   • In both cases it errors rather than waits. litewire calls none of these. ePHPm's snapshot apply calls execute_batch on a dedicated connection.
3. API additions: TransactionBehavior::Concurrent (this breaks exhaustive matches; litewire has none), Builder::with_io(impl Into<IoBackend>), Builder::read_only, and Error::BatchStatementFailed / Error::BatchRollbackFailed.
4. CDC: the code moved into a new turso_core::cdc module. The turso_cdc / turso_cdc_version schema is unchanged (version v2, same columns and change_type values), and DDL is still captured as sqlite_schema row changes.
5. Engine fixes worth knowing about: WAL data committed before the first checkpoint now survives a crash; the WAL is fsynced before checkpoint backfill; pragma names are matched case-insensitively; table-valued PRAGMA row ids reset on each scan; a database with a garbage header is reported as "file is not a database"; an MVCC+CDC panic on an empty COMMIT is fixed.

Database file compatibility (tested)

I built a probe twice, once against turso 0.7.2 and once against 0.8.2. The two turso_core versions export clashing #[no_mangle] symbols, so they cannot share one binary. Each run wrote an ePHPm-shaped database: CDC full, a table with an index, TEXT/REAL/BLOB data, an UPDATE, a DELETE and a metadata table.

Scenario	Result
0.7.2 writes and shuts down cleanly; 0.8.2 opens it	integrity_check ok, 299/299 rows (table and index agree), 612 turso_cdc rows, version v2
0.8.2 writes more to that file	change_id continues 612 → 718 (still monotonic)
litewire CdcTailer + apply_batch over the mixed 0.7.2/0.8.2 log	359 batches, replica identical (348 rows)
Crash image: db plus a 3.9 MB uncheckpointed 0.7.2 -wal, copied while open, opened by 0.8.2	recovered, integrity_check ok, all rows, writes and tail/apply work
Downgrade: a file written by 0.8.2 opened by 0.7.2, and the upgraded file reopened and written by 0.7.2	integrity_check ok, rows intact

Verification

All of these ran on Windows with toolchain 1.99:

• cargo fmt --all -- --check: clean.
• cargo clippy --workspace --all-targets [--all-features] -- -D warnings: clean.
• cargo +1.88 check --workspace --all-features --all-targets (MSRV): ok.
• cargo deny check: advisories, bans, licenses and sources all ok.
• cargo test --workspace [--all-features]: everything passes except one test, litewire/tests/mysql_multi_tenant.rs::single_tenant_attach_keeps_working_over_the_wire. It also fails on main with turso 0.7.2 on Windows, so it is not caused by this bump. The test uses the rusqlite backend, and a Windows temp path inside a MySQL string literal loses its backslashes, so ATTACH opens a different file. It does not reproduce on Linux CI paths.

[ephpm]

ePHPm Preview — removed

Preview deployment has been torn down.

[ephpm]

ePHPm Preview — deployed (health check pending)

URL	https://ephpm-litewire-pr-46.preview.ephpm.dev
Framework	PHP
PHP	8.5
Deployed in	60.7s

Preview updates automatically on each push to this PR.