Docs: a slow migration and a CLI run at the same time

Every ipx command migrates when it opens the database, so the healthcheck
collided with the daemon while it dropped the old entries columns.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TAC7sLVqfKmY6rsTLXzNgk

docs/history.md

@@ -23,7 +23,11 @@ A whole-repo audit for over-engineering listed twelve things to cut, and all of
   accounts. The adoption's copy was their last reader, but `record_entry` still wrote them, and
   still reset `read` when a title changed, which nothing looked at. Two bugs came from queries
   reading them. `migrate()` now drops them from an existing database (SQLite has had `DROP COLUMN`
-  since 3.35), and a test builds an old table to prove it.
+  since 3.35), and a test builds an old table to prove it. On production each drop rewrote the
+  66 MB `entries` table, about four seconds apiece, so the first start took thirteen. An
+  `ipx status` run in that window failed with `migrating schema`: every `ipx` command migrates when
+  it opens the database, and it collided with the daemon doing the same. A failed `ALTER TABLE`
+  changes nothing, and the database had been copied to `backup/` first anyway.
 - **`interval_mins`**, which `schedule` replaced. An old config that still has the key loads; the
   key is ignored, and the config test carries it to keep that true.
 - **Three dependencies.** `infer` was only asked whether a file is a torrent, and the check after