Rebuild the full schema on a database that resetDatabase() just wiped, without reading the database to decide what to create.

The restore path cannot trust any schema or state read taken here: right after the drops, a replica AND even a freshly-routed primary connection can briefly serve the pre-wipe schema (read-your-writes propagation lag — the same effect VERIFY_RETRY_BACKOFF_MS documents). A lagged answer either routed boot into schema verification against the wiped primary ("missing table settings", via initDb's state check) or made the rebuild skip its CREATEs and die at the next write ("no such table: settings"), leaving the operator's database empty. So every statement here is unconditional and idempotent (IF NOT EXISTS), and nothing is consulted first. A just-wiped database has no legacy tables by definition, so the additive column reconciliation initializeFreshSchema performs (via applySchemaChanges) is not needed here.