Unified Photo Provider Abstraction Layer

[mauriceboe]

Summary

Currently, TREK exposes platform-specific photo IDs (Immich, Synology) directly to the frontend. Each provider has its own flow for selecting and displaying photos, meaning Journal and other components need provider-specific logic. As we already support two providers and may add more in the future (e.g. Google Photos), this approach doesn't scale well.

Proposal

Introduce a unified abstraction layer for photo providers:

• Backend: trek-photo-id — A single internal ID that maps to any provider. The backend resolves it to the actual image source (Immich, Synology, etc.). The frontend never needs to know which provider a photo comes from.
• Backend: Unified photo endpoint — e.g. GET /api/photos/:trekPhotoId that serves the image regardless of provider, handling auth and URL resolution internally.
• Frontend: Generic provider overlay — A single "Pick Photo" component that launches a provider-agnostic selection UI. Provider-specific flows (browse, search, select) are encapsulated behind this overlay.

Why

• Today's problem: With Immich + Synology we already have two providers with different ID schemes and selection flows. Adding provider-specific logic to Journal (and future components) creates maintenance overhead.
• Future-proofing: Adding a new provider becomes a backend-only task (implement the provider interface) instead of touching every component that displays or selects photos.
• Cleaner frontend: Components just work with trek-photo-id and a single image path — no conditional rendering per provider.

Scope

• Define a PhotoProvider interface on the backend
• Create a photos table mapping trek-photo-id → provider + provider-specific ID
• Unified REST endpoint for photo retrieval
• Refactor frontend photo selection into a single generic overlay component
• Migrate existing Immich and Synology integrations to the new abstraction