fix(playlists): thread the source provider id through to recent playlists

Fixes #368.

Reopening a Spotify playlist from "recent access" showed no tracks,
while the first view (right after pasting the URL) worked fine.

Root cause traced across two layers:

1. Go: ExtURLHandleResult (the parsed shape of an extension's handleUrl()
   return value) never captured a top-level `id` for the handled
   resource. Track/album/artist results carry their own id inside their
   nested metadata, but a plain playlist result has no such object, so
   its id was silently dropped everywhere from the goja parser through
   to the JSON the Dart side receives.

2. Dart: TrackState had nowhere to put that id even if it existed
   (only playlistName), so recording a "recent" playlist access stored
   the playlist's *name* as if it were its id. Reopening it later fed
   that name into PlaylistScreen's provider-guessing logic
   (legacyProviderIdFromResourceId, which only recognizes legacy
   "provider:id" prefixes), which naturally failed and fell through to
   a hardcoded Deezer metadata fetch using a Spotify playlist's name as
   the resource id - guaranteed to return nothing.

Fix, matching the "generic API, not per-provider checks" architecture
in CONTRIBUTING.md:

- go_backend/extension_provider_wrapper.go: add ExtURLHandleResult.ID.
- go_backend/extension_goja_convert.go: parse it from the handler's
  return value.
- go_backend/exports_extensions.go: surface it in the JSON response.
- lib/providers/track_provider.dart: add TrackState.playlistId,
  populated from the response's `id` field for playlist results.
- lib/screens/home_tab.dart: record the real playlist id (falling back
  to the name only if a provider never supplies one) and pass both the
  id and the already-known provider id forward to PlaylistScreen.
- lib/screens/playlist_screen.dart: PlaylistScreen gains a
  metadataProviderId param that takes priority over guessing from the
  id's shape.
- lib/screens/home_tab_recent.dart: pass the recent-access entry's
  stored providerId through when reopening a playlist.
- lib/utils/provider_resource_ids.dart: extract the
  known-id-vs-guessed-id preference into a small, directly testable
  resolvePreferredMetadataProviderId helper.

Note: this fixes the common case (an extension already reported its
own id as the source provider for the URL it handled). If a provider
never supplies an id for its handleUrl() playlist result, playlistId
stays null and behavior is unchanged from before this fix - no
regression, just not a complete fix for that narrower case, since
that would require changes in extension-side JS code outside this
repo.

Tests:
- go_backend/extension_goja_convert_url_handle_test.go: the new ID
  field round-trips from a handler's return value, and stays empty
  when the handler doesn't supply one.
- test/provider_resource_ids_test.dart: resolvePreferredMetadataProviderId
  prefers a known provider id, falls back to the legacy-prefix guess,
  treats a blank known id as unknown, and returns null for the
  unprefixed-id-with-no-known-provider case from #368 itself.

Verification: go build/vet/test and flutter analyze/test all green.

lib/providers/track_provider.dart

@@ -19,6 +19,7 @@ class TrackState {
   final String? albumId;
   final String? albumName;
   final String? playlistName;
+  final String? playlistId;
   final String? artistId;
   final String? artistName;
   final String? coverUrl;
@@ -40,6 +41,7 @@ class TrackState {
     this.albumId,
     this.albumName,
     this.playlistName,
+    this.playlistId,
     this.artistId,
     this.artistName,
     this.coverUrl,
@@ -64,6 +66,7 @@ class TrackState {
     String? albumId,
     String? albumName,
     String? playlistName,
+    String? playlistId,
     String? artistId,
     String? artistName,
     String? coverUrl,
@@ -87,6 +90,7 @@ class TrackState {
       albumId: albumId ?? this.albumId,
       albumName: albumName ?? this.albumName,
       playlistName: playlistName ?? this.playlistName,
+      playlistId: playlistId ?? this.playlistId,
       artistId: artistId ?? this.artistId,
       artistName: artistName ?? this.artistName,
       coverUrl: coverUrl ?? this.coverUrl,
@@ -243,6 +247,7 @@ class TrackNotifier extends Notifier<TrackState> {
                 collectionName ??
                 (result['album'] as Map<String, dynamic>?)?['name'] as String?,
             playlistName: type == 'playlist' ? collectionName : null,
+            playlistId: type == 'playlist' ? result['id'] as String? : null,
             coverUrl: normalizeCoverReference(result['cover_url']?.toString()),
             headerVideoUrl: normalizeRemoteHttpUrl(
               result['header_video']?.toString(),

lib/screens/home_tab.dart

@@ -598,13 +598,14 @@ class _HomeTabState extends ConsumerState<HomeTab>
     }
 
     if (trackState.playlistName != null && trackState.tracks.isNotEmpty) {
+      final playlistProviderId = trackState.searchExtensionId ?? 'spotify';
       ref
           .read(recentAccessProvider.notifier)
           .recordPlaylistAccess(
-            id: trackState.playlistName!,
+            id: trackState.playlistId ?? trackState.playlistName!,
             name: trackState.playlistName!,
             imageUrl: trackState.coverUrl,
-            providerId: trackState.searchExtensionId ?? 'spotify',
+            providerId: playlistProviderId,
           );
 
       Navigator.push(
@@ -614,6 +615,8 @@ class _HomeTabState extends ConsumerState<HomeTab>
             playlistName: trackState.playlistName!,
             coverUrl: trackState.coverUrl,
             tracks: trackState.tracks,
+            playlistId: trackState.playlistId,
+            metadataProviderId: playlistProviderId,
             recommendedService:
                 trackState.searchExtensionId ?? trackState.searchSource,
           ),

lib/screens/home_tab_recent.dart

@@ -342,6 +342,7 @@ extension _HomeTabRecentUI on _HomeTabState {
                 coverUrl: item.imageUrl,
                 tracks: const [],
                 playlistId: item.id,
+                metadataProviderId: item.providerId,
               ),
             ),
           );

lib/screens/playlist_screen.dart

@@ -31,6 +31,7 @@ class PlaylistScreen extends ConsumerStatefulWidget {
   final String? headerVideoUrl;
   final List<Track> tracks;
   final String? playlistId;
+  final String? metadataProviderId;
   final String? recommendedService;
 
   const PlaylistScreen({
@@ -40,6 +41,7 @@ class PlaylistScreen extends ConsumerStatefulWidget {
     this.headerVideoUrl,
     required this.tracks,
     this.playlistId,
+    this.metadataProviderId,
     this.recommendedService,
   });
 
@@ -126,7 +128,10 @@ class _PlaylistScreenState extends ConsumerState<PlaylistScreen>
   }
 
   String? _metadataProviderId(String playlistId) {
-    final providerId = legacyProviderIdFromResourceId(playlistId);
+    final providerId = resolvePreferredMetadataProviderId(
+      widget.metadataProviderId,
+      playlistId,
+    );
     if (providerId == null) return null;
     final effective = resolveEffectiveMetadataProvider(
       providerId,

lib/utils/provider_resource_ids.dart

@@ -18,3 +18,20 @@ String stripPrefixedResourceId(String value) {
   }
   return value.substring(colonIndex + 1);
 }
+
+/// Resolves the metadata provider id to fetch a resource from, preferring a
+/// caller-supplied [knownProviderId] (e.g. from a recent-access entry that
+/// already recorded its source) over guessing from [resourceId]'s shape.
+///
+/// [legacyProviderIdFromResourceId] only recognizes legacy-prefixed ids
+/// ("deezer:...", "spotify:...", etc.); anything else - including a plain,
+/// unprefixed id from a provider that never used that scheme - resolves to
+/// null unless the caller already knows the provider.
+String? resolvePreferredMetadataProviderId(
+  String? knownProviderId,
+  String resourceId,
+) {
+  final known = knownProviderId?.trim();
+  if (known != null && known.isNotEmpty) return known;
+  return legacyProviderIdFromResourceId(resourceId);
+}