schema: collapse config.db to a single baseline, ddl_v1 stays editable until v0.1

docs/how-to/upgrade.md

@@ -307,7 +307,7 @@ opens the database immutable and never migrates, so on a database still one
 version behind it reports the mismatch and exits 2 rather than fixing it:
 
 ```
-FAIL /var/lib/nxdns/config.db: schema version 0, this nxdns expects 4; `nxdns run` migrates it, `check` will not
+FAIL /var/lib/nxdns/config.db: schema version 0, this nxdns expects 1; `nxdns run` migrates it, `check` will not
 ```
 
 That line was reproduced here against a database stamped at version 0; the path
@@ -317,22 +317,21 @@ A fresh database is created at the current schema version; an older one is
 stepped up to it. The log line names both versions:
 
 ```
-info(migrations): config.db migrated from schema version 0 to 4
+info(migrations): config.db migrated from schema version 0 to 1
 ```
 
 > Verified on this host: that exact line is what `nxdns import` printed when it
 > created the scratch database used throughout this page. An empty data
 > directory is schema version 0, which is why a first run reports a migration
-> rather than nothing. The step from a populated older schema to 4 was not
-> reproduced here — it needs a database written by an older binary, which this
-> host does not have.
+> rather than nothing. Version 1 is the only schema nxdns has published, so an
+> upgrade from a populated older one is not a case that exists yet.
 
 Rolling back is the case that has no answer. A database stamped by a newer
 binary refuses to open, so an older binary against an upgraded data directory
 fails to start:
 
 ```
-warning(migrations): config.db is at schema version 99; this nxdns binary supports 4
+warning(migrations): config.db is at schema version 99; this nxdns binary supports 1
 nxdns run failed: SchemaTooNew
 ```