feat: per-profile separate SQLite logbook file (config never swapped)

Design flaw: the SQLite backend conflated the app/config database (opslog.db —
settings + profiles) with the QSO logbook. connectLogbook returned a.db for any
non-MySQL profile, so the ONLY way to get a separate SQLite logbook was the
whole-app "change database location" pointer — which swapped config + profiles
too, wiping the operator's setup (reported: creating Jerem.db lost all configs).

profile.ProfileDB gains a Path field: a non-empty path routes that profile's
logbook to its own SQLite file (db.Open creates + migrates it on first use),
while opslog.db keeps settings/profiles. connectLogbook opens the file; empty
path = shared db (unchanged default, backward compatible). MySQLSettings carries
sqlite_path; Get/Save wire it through.

UI: the Database panel gains a third backend option "SQLite — separate file"
with a file picker, and now clearly labels the shared application database
(settings + profiles) vs this profile's logbook, so the two are never confused.

internal/profile/profile.go

@@ -26,6 +26,13 @@ type ProfileDB struct {
 	User     string `json:"user"`
 	Password string `json:"password"`
 	Database string `json:"database"`
+	// Path is a per-profile SQLite logbook FILE, distinct from the shared app
+	// database (opslog.db, which always holds settings + profiles). Empty =
+	// the shared database is used as the logbook (the historical default). Set =
+	// this profile's QSOs live in their own .db, so a visiting operator's contacts
+	// don't mix into yours and switching it never touches your config. Only used
+	// when Backend != "mysql".
+	Path string `json:"path,omitempty"`
 }
 
 // Profile is one operating configuration. A user typically keeps a few: