Replacing inspector profile photos fails

Objective

• Staff with Settings → Inspectors access must be able to replace an inspector's profile photo and see the new image immediately on the inspector settings page.
• The updated photo must persist after refresh and appear anywhere the product reads the inspector's thumb / image fields (e.g. inspector list, scheduling, emails).
• Fix the reported failure for Residential Inspector (Catherine Lemoine) where replacing photos (e.g. Eli's) did not work across multiple inspectors and image files.

Background

• Product feedback from Catherine Lemoine (catherine@residentialinspector.com): unable to replace Eli's profile picture; same behavior on multiple inspectors and photos, so this does not look limited to one profile or file.
• Repro attempt in progress internally using the same inspector image files.
• Short video shows the behavior.
• Code triage indicates the upload path exists but the UI/state flow is fragile: FilePond upload completes before the inspector PATCH finishes, local state only updates thumb (not image), and a useEffect can reset state from stale server data after cache revalidation.
• Triage verdict: Bug — intended behavior is that photo replacement works; current implementation can leave the old photo visible even when upload or save partially succeeds.
• Edge case to rule out during repro: Spectora bulk sync (POST /inspector/sync-inspectors) and manual Spectora re-sync (ResyncSpectoraModal) can overwrite image / thumb from Spectora, reverting manual uploads.

Scope

Frontend (attik-frontend)

• Inspector settings page: src/app/tools/settings/inspectors/[id]/InspectorForm.tsx — ProfilePicUploader with handleImageUpload PATCHes inspector/{id} with { image: file.url, thumb: file.preview }; on success shows toast and setData({ ...data, thumb: file.preview }) only (no router.refresh(), image not updated locally).
• Shared uploader: src/components/ui/ProfilePicUploader.tsx — FilePond uploads via callServerAction → POST files with path: profile-pic; calls handleUpload(resp) without awaiting before closing the editor.
• Server action / cache: src/util/functions/fetching/callServerAction.ts — revalidate uses path /settings/inspectors (other settings forms use /tools/settings/...).
• Same uploader pattern on office staff: src/app/tools/settings/office/[id]/OfficeForm.tsx — likely same class of bug if fix is shared.
• Spectora manual re-sync (separate from upload): src/app/tools/settings/ResyncSpectoraModal.tsx and DataForm.tsx handleResync can overwrite profile image from Spectora.

Backend (attik-backend)

• File upload: src/routes/files.ts — POST /files with multipart, path: profile-pic → S3 upload + thumbnail preview URL in response.
• Inspector update: src/routes/inspector.ts — PATCH /:id saves any defined schema fields including image and thumb.
• Spectora bulk sync: POST /sync-inspectors in same file always sets image and thumb from Spectora on findOneAndUpdate.
• Inspector schema: src/models/inspectorSchema.ts — image and thumb are string fields.

Out of scope (unless repro proves otherwise)

• Mobile app inspector profile editing (report is web Settings → Inspectors).
• Contact profile photos (different form path in ContactForm.tsx).
• Inspector photos in email delivery / CDN loading (see completed ATT-1780 — separate concern).

References

• Video showing profile photo issue
• Slack thread — Catherine Lemoine report
• Frontend entry: attik-frontend/src/app/tools/settings/inspectors/[id]/InspectorForm.tsx
• Backend entry: attik-backend/src/routes/files.ts, attik-backend/src/routes/inspector.ts

Decisions needed

1. Source of truth for Spectora-linked inspectors — When an inspector has a _specId, should a manually uploaded Attik profile photo override Spectora's image / thumb until explicitly re-synced, or should Spectora remain authoritative and Attik uploads be blocked/warned for linked inspectors?
2. Spectora re-sync behavior — Should manual Spectora re-sync (ResyncSpectoraModal) and bulk sync (POST /inspector/sync-inspectors) skip image / thumb when Attik has a custom upload, or continue overwriting (current behavior)?
3. Scope of fix — Should the same fix apply to office staff profile photos (OfficeForm.tsx uses the same ProfilePicUploader pattern), or is this ticket inspectors-only?
4. Done criteria / surfaces — Is success defined as the photo updating on the inspector settings page only, or must it also update immediately on the inspector list, scheduling UI, and email previews without a separate cache delay?
5. Repro confirmation — After internal repro with Catherine's image files: confirm whether failure is upload error, PATCH error, UI revert with successful save, or save lost on refresh — this determines whether the fix is frontend-only or also backend/sync-related.
6. User messaging on failure — If upload or save fails, should the product show a clear error (and keep the editor open) rather than closing FilePond and showing the old photo with no explanation?