refactor(core): preserve playlist data during SQLite schema drift recovery

[Copilot]

Playlist data should survive schema drift, unlike cache-like tables (library/media/progress). This change moves recovery from “recreate DB” to table-level reconciliation and simplifies playlist item persistence to only durable identifiers.

• Database recovery strategy

  • Reworked DatabaseService initialization to detect per-table schema drift via PRAGMA table_info.
  • Replaces only drifted cache tables (library_folders, media_records, playback_progress).
  • Migrates playlists and playlist_items through *_new tables to preserve playlist data.
  • Keeps full DB file deletion as last-resort fallback only.

• Playlist schema simplification

  • Reduced playlist_items to minimal durable fields:
    • id, playlist_id, path, sort_order
  • Removed duplicated metadata columns previously copied from media records.

• Runtime data composition for playlists

  • Updated PlaylistService writes to persist only path/order.
  • Updated reads to hydrate playlist item metadata by joining playlist_items with media_records on path.
  • Added safe fallback title derivation from path when joined metadata is missing.

• Internal DB DTOs (no tuple transport)

  • Introduced internal DTOs in Screenbox.Core (DatabaseDtos.cs) for cache load/write and SQL parameter transport.
  • Refactored LibraryService DB transport paths to use DTOs instead of tuple-based contracts.

SELECT pi.path,
       mr.title, mr.media_type, mr.date_added, mr.duration_ticks, mr.year,
       mr.artist, mr.album, mr.album_artist, mr.composers, mr.genre, mr.track_number,
       mr.subtitle, mr.producers, mr.writers
FROM playlist_items pi
LEFT JOIN media_records mr ON mr.path = pi.path
WHERE pi.playlist_id = @pid
ORDER BY pi.sort_order, pi.id;