PhotoVideoBackup: SSD Transfer

| 2.5.0 | 46 | 2026-08-28 | Feature | **Clearer backup progress, and no more duplicate files in a folder.** Two things. **(1) Visibility.** Tapping a backup button now gives an *instant* acknowledgment — the progress card appears immediately, even before the destinations are resolved (previously the card only showed after the NAS was contacted, so the tap felt ignored). During the long, previously-opaque preparation, a real status is shown: **"Analyzing source…"** with a **live count of files found**, replacing the generic "Initializing…" spinner — so you can see the app is working even before the first file is copied. And the in-progress card is **pinned so it is always visible** without scrolling past the destinations and sources. Implemented with a `BackupPhase` (`preparing → scanning → copying`) on `DashboardViewModel`, a throttled scan-count callback funneled through `MediaScanner.mediaFile` / `PHLibraryScanner`, and a `.safeAreaInset(edge:.bottom)` progress card. **(2) Deduplication.** A new cascade level (`existingLocalTwinPath`) scans the actual destination folder for a **byte-identical file under a different name** before copying — size is the free filter, SHA-256 the confirmation — so a folder never ends up with two physical copies of the same content *regardless of how the first copy got there* (this app, an older version, or a Finder copy). This fixes the field report of `Insta360LunaUltra.mp4` / `Insta360LunaUltra-1.mp4` both landing on the SSD: the twin was left there by a prior transfer the SHA index never knew, so the identical file was re-copied. Applies to both engines; a covered target also backfills the SHA index so the next run skips it via the cheap index path. Pure function, unit-tested by `TwinDedupTests`. Also: the **Diagnostic** log button now emails with the same routable `[Support:PhotoVideoBackup]` subject + `SUPPORT-META` block as Contact Support (`AppConstants.diagnosticMailtoURL`), so log sends triage automatically like any other request. **(3) Faster start for SD-card / camera backups.** Reading each file's capture date (EXIF / video-container metadata) was the slow part of preparing an external-source backup — done up front for every file before the first copy. It is now **deferred**: the scan reads only cheap file info and the capture date is resolved per-file inside the copy loop, so the scan is near-instant and the first file starts almost immediately (measured on device: a 28-photo SD scan went from a 2–3 s gap between scan and first copy down to ~0 s; it scales with library size). The date value and destination folders are unchanged. A missing **device name** is now also checked *before* the scan (fail-fast) instead of after. Photos-library backups are unaffected by this (a `PHAsset`'s date is already cheap; that path's separate bottleneck, `PHAssetResource.assetResources`, is a later change). See `MediaScanner.resolveCaptureDate` + `DeviceScannerTests`. |