fix(scanner): backfill PIDArtist property on upgrade

A user upgrading from a pre-PID.Artist version with a non-default
PID.Artist already configured would have hit a silent annotation
loss: empty stored PIDArtistKey was normalized to the current
config, pidHashChanged returned false, no full rescan was forced,
and prevArtistPIDConf stayed empty during the next normal scan so
the artistIDMap guard skipped annotation migration entirely.

Backfill via migration so the stored value reflects the historical
default ('name', byte-identical to the legacy hardcoded artistID).
Drop the empty-string fallback in pidHashChanged — with the
migration in place, an empty stored value would be anomalous, and
the fallback was the exact dead branch that hid this hole.

cmd/root.go

@@ -179,10 +179,6 @@ func pidHashChanged(ds model.DataStore) (bool, error) {
 	if err != nil {
 		return false, err
 	}
-	// Empty stored value is treated as matching — fresh upgrade should not force a rescan.
-	if pidArtist == "" {
-		pidArtist = conf.Server.PID.Artist
-	}
 	return !strings.EqualFold(pidAlbum, conf.Server.PID.Album) ||
 		!strings.EqualFold(pidTrack, conf.Server.PID.Track) ||
 		!strings.EqualFold(pidArtist, conf.Server.PID.Artist), nil

db/migrations/20260525000912_set_default_pid_artist.sql

@@ -0,0 +1,11 @@
+-- +goose Up
+-- Backfill PIDArtist property to reflect the historical artist-ID computation.
+-- Existing artist IDs were produced by the legacy hardcoded artistID() function,
+-- which is byte-identical to computeArtistPID(p, "name", ...). Recording "name"
+-- here ensures that on the next scan, prevArtistPIDConf is never empty — closing
+-- the upgrade-time window where a user who pre-configured a non-default PID.Artist
+-- would have artist IDs silently regenerated without annotation migration.
+insert into property (id, value) values ('PIDArtist', 'name') on conflict do nothing;
+
+-- +goose Down
+delete from property where id = 'PIDArtist';