fix(db): a migration aimed at a table a database no longer holds must not kill the startup

The 0031 clublog ALTER hit split settings databases (their qso table
moved to the logbook years of QSOs ago) and the whole open failed —
silently, because the error went to a println the GUI subsystem
discards. The app then ran with no settings store: every panel showed
defaults, 'db not initialized' in Preferences, and operators read it as
their database being lost. Nothing was ever touched: the failed
migration rolled back on every attempt.

The SQLite migration path now tolerates what the MySQL path always has —
plus the one case it never meets: ALTER/CREATE INDEX/DROP on a table
this database legitimately does not hold. And a failed open is written
to the rotating log, where the next such morning can actually be
diagnosed.

app.go

@@ -1132,7 +1132,9 @@ func (a *App) startup(ctx context.Context) {
 	conn, err := db.Open(a.dbPath)
 	if err != nil {
 		a.startupErr = "cannot open db: " + err.Error()
-		fmt.Println("OpsLog:", a.startupErr)
+		// In the rotating log too: the GUI subsystem discards stdout, and this
+		// exact failure once hid for a whole morning behind a println.
+		applog.Printf("startup: %s", a.startupErr)
 		return
 	}
 	a.db = conn