Review of the foreign-schema heal found two gaps in what it claimed to cover:
- `_BASE_TASK_COLUMNS` said it listed the nullable/defaulted v1 columns but
omitted `priority`, `created_by` and `completed_at`. A harness that seeded
`tasks(id,title,assignee,status,created_at,started_at)` connected fine and
then failed `list_tasks` with "no such column: priority" (`SELECT *` feeds
the Task row shape). Add the three entries with DDL copied from SCHEMA_SQL.
- The `assignee` heal was unreachable: `connect()` runs `executescript(SCHEMA_SQL)`
before `_migrate_add_optional_columns`, and SCHEMA_SQL's
`CREATE INDEX idx_tasks_assignee_status ON tasks(assignee, status)` aborts
init on a board without `assignee` before any ALTER runs. Move that index
into the post-ALTER `CREATE INDEX IF NOT EXISTS` block next to the other
additive-column indexes; fresh DBs end up with the identical index.
The existing foreign-schema test now seeds the narrowest schema
(`tasks(id,title,status,created_at)`), asserts all ten healed columns match
the fresh DDL, and reads the board back through `list_tasks`.
The "already fully migrated" fixture in
`test_migrate_add_optional_columns_tolerates_concurrent_migration` gains the
v1 `status` column the assignee/status index now needs (a real migrated board
always has it).
0cb7a2fd60