iris
297e85c68d
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.