[BORNIOS]

Qué pasaba

Jellyfin registra en __EFMigrationsHistory tanto sus rutinas de código como las migraciones del proveedor, y todas comparten la forma yyyyMMddHHmmss_nombre. El plugin no llevaba el historial de rutinas al importar desde SQLite, así que Jellyfin las volvía a ejecutar al arrancar. Las rutinas antiguas como RemoveDuplicateExtras abren library.db, que en una instalación nueva de 12.x ya no existe, y el arranque fallaba con no such table: TypedBaseItems.

Detalle del reporte original que conviene aclarar: "yyyyMMddHHmmsss" en .NET produce 14 dígitos, no 15, así que el filtro anterior (id[15] == '_') nunca coincidía. Aceptar 14 dígitos tampoco habría servido: los ids de las migraciones de esquema del proveedor también tienen 14, y habrían entrado al historial de PostgreSQL como si estuvieran aplicadas.

Qué cambia

• Se copian del historial de SQLite solo los ids que corresponden a un tipo con JellyfinMigrationAttribute, identificados por el nombre de la migración (RemoveDuplicateExtras, MigrateActivityLogDb, …), no por el formato del id.
• Si no se descubre ningún tipo de migración, no se toca el historial y queda registrado en el log; si no se copia ninguna, se advierte que Jellyfin podría volver a ejecutar rutinas que necesitan library.db.
• Se elimina el filtro muerto basado en 15 dígitos.

Pruebas

• 6 unitarias del identificador: acepta rutinas conocidas, rechaza migraciones de esquema y nombres desconocidos.
• 2 de integración: se copia la rutina aplicada con su ProductVersion y no una migración de esquema; sin tipos descubiertos el historial queda intacto.
• Suite completa contra PostgreSQL 17: 126 correctas, 0 fallidas, 1 omitida.

Fixes #9