milestone 13 discrepancies: redact credentials from urls in logs, metrics and cli output

docs/explanation/configuration-model.md

@@ -59,11 +59,35 @@ time you look at the UI, rather than "my edit was applied and then quietly
 undone next Tuesday".
 
 The emptiness check is a real query over the content tables, not a flag: the
-database counts as configured when any content table has rows, or when the
-default group has been altered. One consequence is worth knowing, because it
-is not obvious: clients are auto-materialised when they first send a query, so
-a server that has answered even one query is "configured" and will ignore a
-seed file placed there afterwards.
+database counts as configured when a content table holds rows, or when the
+default group has been altered. What it measures is intent, not activity, and
+the client table is where those two come apart. Clients are auto-materialised
+when they first send a query — the DNS path writes a row per device it sees —
+and such a row records what the network did, not what an operator decided. It
+carries `hand_edited = 0`, the emptiness check counts only the `hand_edited = 1`
+rows, and `export` omits them. So answering queries never turns an unconfigured
+database into a configured one; naming a device does.
+
+Counting traffic here would have been a quiet trap: a server that resolved one
+name would have declared itself configured and ignored a seed file placed
+afterwards, and the operator would have had no line of output saying why.
+
+The same distinction survives an import. `import` replaces the content in one
+transaction, which empties `clients` along with every other table, so every
+client row is saved before the wipe. The materialised ones are put back after it
+unchanged, and restoring a backup does not make the server forget the devices it
+has met.
+
+An address the imported file names belongs to the file — the operator's
+statement wins over the discovered row — with one carve-out. First-seen and
+last-seen are not configuration: they record when a device was heard from, the
+configuration model has no field for either, and an import is not a query. So
+they follow the address rather than the row. If the database already knew that
+address, its two timestamps are carried onto the new row; only an address the
+database has never seen takes the import's clock. Without that, re-importing a
+backup would stamp every device the operator had bothered to name as though it
+had just arrived — and those are exactly the devices whose history is worth
+something.
 
 ## The round trip
 
@@ -90,11 +114,17 @@ difference is a configuration change, never noise from when the export ran.
 
 `nxdns import` replaces the whole database content in one transaction. Not a
 merge, not a patch: delete every content table in foreign-key-safe order, then
-insert what the file says. A failed import — bad syntax, failed validation, a
-constraint violation halfway through — leaves the database exactly as it was,
-because everything happens inside a single `BEGIN IMMEDIATE`.
+insert what the file says — with the one exception described above. Every client
+row is lifted out first. The materialised ones are put back rather than
+recreated from a file that never held them, and the observed timestamps of an
+address the file *does* name are merged onto its new row. A client the file
+leaves out is gone, history included: nothing puts a `hand_edited = 1` row back.
+A failed import — bad syntax, failed
+validation, a constraint violation halfway through — leaves the database exactly
+as it was, because everything happens inside a single `BEGIN IMMEDIATE`.
 
-Without `--force`, import refuses a database that already has content. That
+Without `--force`, import refuses a database that already holds configuration.
+That
 check runs *inside* the transaction, after the lock is taken, so it cannot be
 raced by a concurrent write. The effect is that a plain `import` can never
 clobber a configured server by accident, and clobbering it deliberately takes