fix(ci): move MIGRATION_025 above the test module

clippy's items_after_test_module fired on schema.rs: the new migration
const was appended to the end of the file, which is after the
#[cfg(test)] block added alongside migration 024.

    error: items after a test module
      --> src/storage/schema.rs:901:1

Only visible under --all-targets, which compiles the test target; the
--lib run I checked locally cannot see it. CI runs --all-targets, so it
failed there and nowhere else. Verified this time with the exact CI
invocation rather than a narrower one.

src-tauri/src/storage/schema.rs

@@ -897,6 +897,30 @@ INSERT OR IGNORE INTO download_grants (user_id, download_id)
 SELECT d.user_id, d.id FROM downloads d;
 "#;
 
+/// Force cached items to be re-fetched so `library_id` is populated.
+///
+/// `save_to_cache` bound `library_id` NULL for every row it wrote, so nothing in
+/// the cache knew which library it came from. The only available association was
+/// the `collection_type` ↔ `item_type` taxonomy, which cannot tell two libraries
+/// of the same type apart — a server with "TV" and "Shows" served both the same
+/// contents — and says nothing at all about a library whose type it does not map
+/// (Books, Photos, Collections, or a mixed library where Jellyfin sends no
+/// collection type).
+///
+/// The write path now records the library. Existing rows cannot be repaired
+/// locally — the association was never stored — so they are marked stale and
+/// re-fetched on next browse, exactly as MIGRATION_018 did for `is_folder`.
+///
+/// Deliberately does not delete anything: downloads, favourites and playback
+/// positions live in other tables and are untouched, and a cleared `synced_at`
+/// only means "ask the server again", so an offline user keeps browsing what
+/// they already had until the next successful fetch.
+///
+/// TRACES: UR-007 | DR-278
+const MIGRATION_025: &str = r#"
+UPDATE items SET synced_at = NULL;
+"#;
+
 #[cfg(test)]
 mod migration_024_tests {
     use super::*;
@@ -1068,27 +1092,3 @@ mod migration_024_tests {
         assert_eq!(count(&conn, "SELECT COUNT(*) FROM download_grants"), 0);
     }
 }
-
-/// Force cached items to be re-fetched so `library_id` is populated.
-///
-/// `save_to_cache` bound `library_id` NULL for every row it wrote, so nothing in
-/// the cache knew which library it came from. The only available association was
-/// the `collection_type` ↔ `item_type` taxonomy, which cannot tell two libraries
-/// of the same type apart — a server with "TV" and "Shows" served both the same
-/// contents — and says nothing at all about a library whose type it does not map
-/// (Books, Photos, Collections, or a mixed library where Jellyfin sends no
-/// collection type).
-///
-/// The write path now records the library. Existing rows cannot be repaired
-/// locally — the association was never stored — so they are marked stale and
-/// re-fetched on next browse, exactly as MIGRATION_018 did for `is_folder`.
-///
-/// Deliberately does not delete anything: downloads, favourites and playback
-/// positions live in other tables and are untouched, and a cleared `synced_at`
-/// only means "ask the server again", so an offline user keeps browsing what
-/// they already had until the next successful fetch.
-///
-/// TRACES: UR-007 | DR-278
-const MIGRATION_025: &str = r#"
-UPDATE items SET synced_at = NULL;
-"#;