fix(app): an installed database gains the columns a new build needs

Review threads live on the whole diff, not on one commit, so none are shown here - a thread's line means something in the branch's final form, and painting it into an intermediate step would put it on code it is not about.

app/Uplink/sqlite-store.tsmodified+4-0

Changes to app/Uplink/sqlite-store.ts

		⋯45 linesShow the 45 lines above this hunk@@ -46,6 +46,10 @@ export interface TableSpec {
46	46	* databases that already exist, so it has to be one SQLite can ALTER in:
47	47	* nullable or carrying a constant default, and never PRIMARY KEY or UNIQUE.
48	48	*
	49	+ * Only missing columns are added. Changing a definition here, a default or a
	50	+ * type, reaches new databases and no existing one, which is the original bug
	51	+ * in a quieter form. A change like that needs its own step, not an edit.
	52	+ *
49	53	* Worth knowing before trusting a green test: SQLite only enforces the
50	54	* NOT NULL and constant-default halves once a table has rows. An empty one
51	55	* accepts both. So a new column can pass on a fresh database and fail on

tests/unit/uplink/sqlite-store.test.tsmodified+5-0

Changes to tests/unit/uplink/sqlite-store.test.ts

		⋯170 linesShow the 170 lines above this hunk@@ -171,6 +171,11 @@ describe('SqliteStore migrations', () => {
171	171	* someone adds a column that could not travel.
172	172	*/
173	173	it('can add every column to a shipped database that is already in use', () => {
	174	+ // A table added after 0.1.3 would be created rather than altered, and this
	175	+ // test would quietly stop covering it. Add it to SHIPPED, or state here
	176	+ // why it does not need the guard.
	177	+ expect(TABLES.map(table => table.name).sort()).toEqual(Object.keys(SHIPPED).sort())
	178	+
174	179	const path = join(tempDir(), 'uplink.sqlite')
175	180	write(path, SHIPPED)
176	181	const used = new Database(path)