Aug 19 - Fixed photo-loss issue

JanitorialQC/Models/PendingPhoto.swift

@@ -22,7 +22,20 @@ final class PendingPhoto {
     /// Populated after successful upload
     var serverPath: String?
     /// "pending" | "uploaded" | "failed"
+    ///
+    /// "failed" is TERMINAL: it means every upload attempt was used up, and it
+    /// is what lets processInspectionQueue stop waiting and submit without this
+    /// photo. A *transient* error must therefore leave the row "pending" — see
+    /// `uploadRetryCount`. Marking "failed" on the first error is what turned a
+    /// single dropped connection into a permanently lost evidence photo.
     var uploadStatus: String
+    /// Consecutive failed upload attempts. The row stays "pending" — and so
+    /// keeps blocking its parent's submission — until this reaches
+    /// `SyncManager.maxPhotoUploadAttempts`.
+    ///
+    /// Non-optional with an inline default so SwiftData migrates lightweight
+    /// (CLAUDE.md rule 8): rows in existing stores read as 0.
+    var uploadRetryCount: Int = 0
     var createdAt: Date
 
     // ── Capture metadata (sent to the server, burned into the photo) ───────
@@ -53,6 +66,7 @@ final class PendingPhoto {
         self.fieldId          = fieldId
         self.serverPath       = nil
         self.uploadStatus     = "pending"
+        self.uploadRetryCount = 0
         self.createdAt        = Date()
         // Fall back to now when the caller has no recorded capture moment —
         // still far better than the server's upload-time default.