Serve: auto-recover LMDB format corruption (sequential wipe + rebuild)

[flupkede]

Follow-up to the dependency wave (#249: arroy 0.5→0.8, heed 0.20→0.22). After deploying a binary built on the new storage majors, every repo whose on-disk DB was written by the old binary fails its symbol rebuild with MDB_BAD_VALSIZE: Unsupported size of key/DB name/data, or wrong DUPFIXED size — observed on all C# repos. The tantivy FTS side already self-heals (graceful reset, #253); the vector/symbol stores had no such recovery and stayed red until an operator force-reindexed by hand.

What

• Detection: ServeState::is_lmdb_format_corruption classifies the error chain (MDB_BAD_VALSIZE / Unsupported size of key / wrong DUPFIXED size, case-insensitive) in the symbol-rebuild failure path.
• Recovery: the affected alias is queued; the recovery worker evicts it exactly like remove_repo (stop FSW → evict → await watcher/index shutdown) minus the unregister, wipes the DB dir with the same bounded lock-retry, and starts a force reindex via spawn_force_reindex — whose try_open_stores recreates fresh stores on the new formats.
• Sequential, 1 per 1: a single worker drains the queue; it waits for each rebuild to finish (poll is_indexing, generous cap) before starting the next, because every rebuild is a full CPU-bound embed pass. Queue + started-flag are checked under one lock so a worker exit can never race an enqueue into a lost wake-up.
• Read-only repos are skipped with a pointer to the owning writer (same guard as TUI force reindex).

Tests

• is_lmdb_format_corruption_matches_known_lmdb_errors — table-driven detection (real LMDB message, heed-wrapped, false positives excluded).
• enqueue_format_recovery_dedupes_and_starts_single_worker — duplicate enqueues collapse to one entry; worker flag set.

Changelog

### Fixed entry under the pending version describing the auto-recovery.