Add nullable columns without a default

Deploying knowledge bases showed the migration runner doing the wrong thing:

    ALTER TABLE "documents" ADD COLUMN "base_id" VARCHAR(32) DEFAULT ''

`base_id` is nullable and its absent value is NULL, but the runner derived a
default from the column type and backfilled every existing row with the empty
string. Nothing then matched `base_id IS NULL`, so the startup sweep that files
pre-bases documents into a default base would have skipped all of them and the
documents would have stayed invisible.

Nobody lost anything -- the live instance had no documents yet -- but the fault
is general: any nullable column added from here would arrive as "" rather than
NULL, and every "is this set?" check would be wrong about the rows that predate
it. So a default is now emitted only for NOT NULL columns, where SQLite requires
one.

The sweep also accepts "" as meaning unfiled, since a deployment that upgraded
through the previous release has rows holding it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -19,7 +19,7 @@ lembas info                         # paths + counts, useful when confused
 lembas secret-key                   # generate LEMBAS_SECRET_KEY
 lembas create-admin                 # create or promote an admin
 
-pytest                              # 437 tests, ~27s
+pytest                              # 440 tests, ~28s
                                     # PLAN.md tracks what is and is not built
 ruff check .                        # lint (line length 100)
 python scripts/build_artwork.py     # regenerate artwork (SVG + PWA icons;
@@ -402,6 +402,12 @@ models against the live database and issues `ALTER TABLE ... ADD COLUMN` for
 anything missing, so adding a column to a model is free: restart and it appears,
 with existing rows backfilled from a type-derived default.
 
+**A nullable column is added with no default**, so existing rows get NULL --
+the value the model treats as absent. Only a NOT NULL column gets one, because
+SQLite refuses to add one without. An earlier version defaulted every column by
+type, which meant an added foreign key arrived as `""` on old rows and every
+"is this set?" check downstream was wrong about them.
+
 It cannot rename, drop or retype a column, or add a UNIQUE/PRIMARY KEY to an
 existing table — SQLite mostly cannot do those with ALTER TABLE either. Those
 need the create-copy-swap dance by hand; record them in `MANUAL_STEPS` so a