fix(scan): stop auto-queuing backfill_gps on every startup

`_scan_all_source_roots_async` unconditionally dispatched backfill_gps
30s after each container boot. backfill_gps then queued one
extract_metadata task for every photo where latitude IS NULL — which is
most of the library (screenshots, indoor shots, scans, anything without
GPS in EXIF). The result was ~60k extract_metadata tasks piling onto
the default queue at every deploy, pinning worker-light at 180+% CPU
for ~30 min while it re-derived metadata that wasn't going to change.

The "scanned-before-the-GPS-fix" rationale in the original comment
hasn't applied for many releases. Manual trigger via
POST /api/v1/library/backfill-gps is preserved for the rare case where
the extractor really did change.

backend/app/tasks/scan.py

@@ -461,13 +461,16 @@ async def _scan_all_source_roots_async():
         except Exception as e:
             logger.warning(f"Could not queue post-scan vision backfill: {e}")
 
-        # Re-extract metadata for photos missing GPS coordinates.
+        # NOTE: we used to auto-queue `backfill_gps` here so photos
-        # Runs on every startup so photos scanned before the GPS fix
+        # scanned before the GPS-extraction fix would eventually get
-        # eventually get their coordinates populated.
+        # their coordinates populated. That fix shipped a long time
-        try:
+        # ago, so on every modern restart it just re-ran
-            backfill_gps.apply_async(countdown=30)
+        # extract_metadata for every photo that legitimately has no
-        except Exception as e:
+        # GPS in EXIF (screenshots, indoor shots, scans) — tens of
-            logger.warning(f"Could not queue post-scan GPS backfill: {e}")
+        # thousands of pointless tasks that saturated worker-light
+        # for ~30 min after each deploy. Trigger manually via
+        # POST /api/v1/library/backfill-gps if you ever need it
+        # again (e.g. another extractor-logic fix lands).
 
 
 WATCHER_LOCK_KEY = "mulita:watch_folders:lock"