fix(migrations): say why foreign keys go off, accurately

The note on 0009 and 0012 said the drop would cascade and take every row with it.
It would not: nothing references `activity` or `attachments`, so dropping either
takes nothing along. That claim was carried over from 0008, where seven tables do
reference `tasks` and it is exactly right.

The real reason is the check that comes with the marker. With foreign keys on, the
copy is validated a row at a time against a half-rebuilt schema, and the first bad
row aborts with no idea how many others are like it. With them off,
`PRAGMA foreign_key_check` runs once before the commit and names what is actually
wrong — which matters, because these run against a live database on somebody's
next restart and a failed migration is a server that does not start.

The upgrade test now carries activity rows, an attachment and a group across all
five migrations rather than stopping at 0008, and checks that the columns added by
ALTER arrived with their defaults rather than as NULL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

internal/store/migrations/0012_groups_are_places.sql

@@ -10,9 +10,16 @@
 --
 -- The attachments table has to be rebuilt for the second, because its CHECK spells
 -- out exactly which parent columns may be set, and SQLite cannot alter a CHECK.
+--
 -- Foreign keys go off for the length of it — see the marker below and the note in
--- `applyMigration` — because dropping the old table with them on is a cascading
--- delete of every attachment in the instance.
+-- `applyMigration`. Not because the drop would cascade: nothing references
+-- `attachments`, so it takes nothing with it. It is for the check that comes with
+-- the marker. With foreign keys on, the copy is validated a row at a time against
+-- a half-rebuilt schema and the first bad row aborts with no idea how many others
+-- there are; with them off, `PRAGMA foreign_key_check` runs once before the commit
+-- and names what is actually wrong. This runs against a live database on somebody's
+-- next restart, and an attachment whose task was already gone would otherwise stop
+-- the server from starting with one row's worth of explanation.
 --
 -- The rule stays "exactly one parent": an attachment belongs to a task, a comment
 -- or a group, never two. An attachment with two parents is one that gets deleted