Delete the pre-setups migration, which has done its job

The rule is that migration code goes once the update carrying it has been
received, because there is one backend and one phone: once they are past
a shape, nothing anywhere is still on it, and a second parsing path that
nothing exercises only constrains later changes to the schema. The
module's own comment said to delete it "once the host has started on a
build containing it", and that has happened -- it is in the pushed commit
the host reports itself up to date with, and the server has been starting
on it.

Out: the `legacy` module, `migrate_from_pre_setups`, the branch in
`Config::load` that reached it, and the test. `Config::load` is now one
expression.

PLAN.md keeps the history rather than reverting to what it said before,
because the interesting part is not the migration but the decision it
replaced: refusing to start on an old config was the wrong trade and
proved it on Iris's host, as a crash loop that could not explain itself
because the crashing process is how the phone reaches the machine at all.

Verified by running it, since the point of this change is what happens at
startup: a server with no existing state starts, generates its CA, prints
its enrollment QR and writes a config that reads back. 34 tests, clippy
silent, rustfmt clean.

PLAN.md

@@ -67,10 +67,21 @@ Settled while building it:
   into `config.ron` on first run rather than conjured at read time — a
   provider nobody can see in the file is one nobody can edit from the
   phone, which is the opposite of what this app is for.
-- **No migration; a config in the old shape is refused** with instructions.
-  Unknown fields default away, so `providers:`/`hosts:` would have loaded
-  as an empty config and then been seeded over, losing everything
-  silently.
+- **Migrated once, then the migration was deleted** (2026-08-28). Unknown
+  fields default away, so a `providers:`/`hosts:` file would have loaded as
+  an empty config and then been seeded over, losing everything silently.
+  The first answer to that was to *refuse* such a file, which was the wrong
+  trade and proved it: this process is how a phone reaches the backend at
+  all, so refusing to start stranded the person who would have to fix it,
+  as a crash loop with nothing reachable to explain it. It was replaced by
+  a migration that kept the token hashes, backed the old file up, and
+  rebuilt the rest — which is discoverable now anyway.
+  That migration has since run on the one host there is, so it is gone
+  again, per the standing rule that migration code is deleted once the
+  update carrying it has been received. With one backend and one phone,
+  nothing is left on the old shape, and a second parsing path nothing
+  exercises only constrains later changes to the schema. A file in the old
+  shape now fails to parse, which is correct because no such file exists.
 - **Still to do: editing setups from the phone.** `GET /setups` exists;
   writing them is not built, so a new machine is still a hand edit on the
   backend. That is the remaining gap against the standing preference that