Split TrackApplicationResponse into a Local/External hierarchy

Same treatment as AlbumApplicationResponse, but Track is the cleaner
case: OwnerUserId (local-only) and ExternalId (external-only) are
both genuinely exclusive to one side, so the base carries neither and
is abstract — every real value is one of the two derived types.

    TrackApplicationResponse (abstract, shared fields + FromEntity dispatch)
      LocalTrackApplicationResponse    (+ OwnerUserId)
      ExternalTrackApplicationResponse (+ ExternalId)

Hit a real gotcha along the way: the response already had an explicit
Source property, which collides with the "source" discriminator STJ's
polymorphism support injects ("contains property 'source' that
conflicts with an existing metadata property name" — only surfaced at
runtime in the Api integration tests, not at build time). Fixed by
dropping the now-redundant explicit Source field entirely; the
discriminator already serializes the identical "Local"/"YouTube"
value under the same name, so the wire contract is unchanged. Updated
the two call sites that read .Source directly (TrackSearchItemResponse
and a playlist track filter that needed flatMap instead of
filter().map() to keep the narrowing across the chain).

backend/Tests/Musify.Application.Tests/Tracks/GetTrackByIdQueryHandlerTests.cs

@@ -1,6 +1,7 @@
 using ErrorOr;
 using Musify.Application.Tests.TestSupport;
 using Musify.Application.Tracks;
+using Musify.Application.Tracks.Responses;
 using Xunit;
 
 namespace Musify.Application.Tests.Tracks
@@ -21,7 +22,8 @@ namespace Musify.Application.Tests.Tracks
             Assert.False(result.IsError);
             Assert.Equal("My Song", result.Value.Title);
             Assert.Equal(owner.Name, result.Value.Artist);
-            Assert.Equal(owner.Id, result.Value.OwnerUserId);
+            var localResponse = Assert.IsType<LocalTrackApplicationResponse>(result.Value);
+            Assert.Equal(owner.Id, localResponse.OwnerUserId);
         }
 
         [Fact]