Checkpoint after building the FTS index, or the next boot dies

[jrosskopf]

A gateway that had just rebuilt its index served queries perfectly, and then refused to start again:

escurel-server: fatal: opening DuckDB at …/escurel.duckdb:
Failure while replaying WAL file "…/escurel.duckdb.wal":
Cannot drop entry "fts_main_blocks" because there are entries that depend on it.

PRAGMA create_fts_index(…, overwrite = 1) drops the existing fts_main_blocks schema before recreating it, and DuckDB cannot perform that drop during WAL replay — the dependency ordering replay reconstructs is not the one the live catalog had.

This failure is already documented here, in a different operation

Migrator::ensure_write_attribution names the shape exactly:

…sits in the WAL as a live grenade: the process that ran it keeps working, and the next process to open the file fails to start. That is the worst possible shape for a migration bug — it does not show up until a restart.

The remedy is the one that comment prescribes: CHECKPOINT, folding the operation into the database file and truncating the WAL so there is nothing left to replay.

Observed, not theorised

On the datazoo-loops tenant, whose gateway could not restart at all — every boot needed the index deleted and rebuilt from the lanes, several minutes of re-embedding each time.

I diagnosed it as an unclean shutdown first. That was wrong: it reproduces from a clean stop of a freshly built index.

Verification

By the reproduction that failed twice:

1. clear the index → boot (rebuilds from the lanes) → serves queries
2. stop cleanly
3. boot again — now comes up, where it previously died

Also: no .wal file remains after the stop, and search still returns hits afterwards, so the checkpoint folded in an index that works rather than a broken one.

cargo test --workspace — 1359 passed, 0 failed.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}