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

docs/how-to/back-up-and-restore.md

@@ -99,7 +99,7 @@ nxdns import /tmp/nxdns-lab/backup.zon --data-dir /tmp/nxdns-lab/data-restored
 ```
 
 ```
-info(migrations): config.db migrated from schema version 0 to 4
+info(migrations): config.db migrated from schema version 0 to 1
 imported /tmp/nxdns-lab/backup.zon
 ```
 

docs/how-to/install-with-docker.md

@@ -211,7 +211,7 @@ why the container is `docker-nxdns-1`.
 A healthy first start logs the reconcile, the authority and the bound sockets:
 
 ```
-info(migrations): config.db migrated from schema version 0 to 4
+info(migrations): config.db migrated from schema version 0 to 1
 reconciled '/etc/nxdns/config.zon': upstreams +1 ~0 -0; settings +45 ~0 -0;
 settings keys changed: dns.bind_ipv4 dns.bind_ipv6 dns.port web.bind web.port …
 web authentication is now enabled

docs/how-to/install-with-systemd.md

@@ -225,7 +225,7 @@ nxdns import /etc/nxdns/config.zon
 ```
 
 ```
-info(migrations): config.db migrated from schema version 0 to 4
+info(migrations): config.db migrated from schema version 0 to 1
 imported /etc/nxdns/config.zon
 ```
 

docs/how-to/troubleshoot.md

@@ -424,7 +424,7 @@ asking again reports `rule_block_exact`, `blocked` true and a null `source_url`.
 **Symptom.** After putting an older binary back, it will not 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
 ```
 

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
 ```
 

docs/tutorial/first-run.md

@@ -109,7 +109,7 @@ zig-out/bin/nxdns import ~/nxdns-tutorial/config.zon --data-dir ~/nxdns-tutorial
 ```
 
 ```
-info(migrations): config.db migrated from schema version 0 to 4
+info(migrations): config.db migrated from schema version 0 to 1
 imported /home/you/nxdns-tutorial/config.zon
 ```