feat(admin): metadata-profile picker on integrations page

Persists the operator's metadata-profile choice alongside quality
profile + root folder. Defaults to the first profile Lidarr returns
(usually 'Standard' on a vanilla install) so the common case is
zero-click; operators with custom profiles like 'Singles only' can pick
explicitly.

Backend:
- Migration 0013: adds nullable default_metadata_profile_id to
  lidarr_config. Existing rows get NULL and the service falls back to
  fetch-and-pick-first until they save.
- Updated lidarr_config queries + sqlc + lidarrconfig.Config + admin
  view/put body to round-trip the new field.
- handlePutLidarrConfig requires it (along with QP and root folder)
  when enabled=true — matches the existing missing_defaults gate.
- New GET /api/admin/lidarr/metadata-profiles handler + lidarr.Client
  ListMetadataProfiles (GET /api/v1/metadataprofile, same shape as
  the quality-profile endpoint).
- lidarrrequests.Approve prefers cfg.DefaultMetadataProfileID; falls
  back to the fetch-list path only when 0 (back-compat for upgraders).

Frontend:
- LidarrConfig type + LidarrMetadataProfile type + qk.lidarrMetadataProfiles.
- listMetadataProfiles + createMetadataProfilesQuery client helpers.
- Integrations page: third <select> picker, auto-defaults to first
  profile when the saved value is 0, sends the new field on save and
  clears it on disconnect.
- Updated test fixtures + the duplicate 'Standard' option string in
  the dropdown-populates assertion.

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

internal/lidarrrequests/service.go

@@ -179,20 +179,21 @@ func (s *Service) Approve(ctx context.Context, requestID pgtype.UUID, adminID pg
 	}
 
 	// Lidarr requires a metadata profile id on POST /api/v1/artist (and
-	// on /api/v1/album when it has to create the parent artist). We
-	// don't store this in lidarr_config yet — fetch the available
-	// profiles per-Approve and pick the first as a sensible default.
-	// Lidarr installs ship "Standard" at id=1 OOB, so this works for
-	// vanilla setups; operators with custom profiles get whichever was
-	// saved first. A picker on /admin/integrations is a follow-up.
-	mdProfiles, err := client.ListMetadataProfiles(ctx)
-	if err != nil {
-		return dbq.LidarrRequest{}, fmt.Errorf("approve: list metadata profiles: %w", err)
+	// on /api/v1/album when it has to create the parent artist). Prefer
+	// the operator's pinned choice from cfg; fall back to fetching the
+	// list and using the first when nothing's been saved yet (operators
+	// upgrading from before metadata-profile support landed).
+	mdProfileID := cfg.DefaultMetadataProfileID
+	if mdProfileID == 0 {
+		mdProfiles, mdErr := client.ListMetadataProfiles(ctx)
+		if mdErr != nil {
+			return dbq.LidarrRequest{}, fmt.Errorf("approve: list metadata profiles: %w", mdErr)
+		}
+		if len(mdProfiles) == 0 {
+			return dbq.LidarrRequest{}, fmt.Errorf("approve: no metadata profiles configured in lidarr")
+		}
+		mdProfileID = mdProfiles[0].ID
 	}
-	if len(mdProfiles) == 0 {
-		return dbq.LidarrRequest{}, fmt.Errorf("approve: no metadata profiles configured in lidarr")
-	}
-	mdProfileID := mdProfiles[0].ID
 
 	switch row.Kind {
 	case dbq.LidarrRequestKindArtist: