fix(mobile): avoid duplicate assets in album view

[stfn42]

Description

As outlined in the descriptions on issue #23273, when the same photo is added to multiple albums on Android devices, this results in multiple localAssetEntity rows with the same checksum. The previous LEFT OUTER JOIN on the checksum caused fanning out into multiple duplicate rows, which caused photos to be shown multiple times in the album view (e.g. Shared Albums). Because only the asset query seems to fan out, it also causes offsets to drift, so assets will be rendered with the wrong date.

The most likely root cause for this issue to appear in the first place is probably people receiving photos via various apps and saving them to Camera Roll and defaulting to synching all albums. Ultimately, how many copies of identical photos people want to maintain is a personal choice and the offset drift is still unpleasant.

Fixed by joining against a pre-deduplicated subquery (GROUP BY checksum) instead of the raw table, so each remote asset should only match one local row. Subquery would probably also work, but would be slower on larger albums in particular. Resolves described issue successfully on a Pixel 9 Pro.

Fixes #23273

How Has This Been Tested?

To reproduce the underlying issue, an Android device needs an identical photo to exist in multiple device albums (e.g. Camera and WhatsApp Images).

1. Take a photo
2. Create a new album "Test"
3. Add photo to album "Test". (some applications e.g. Samsung's Gallery suggest moving the file vs. copying, which is sensible, but not helpful here - pick copy)
4. In Immich, select both the Camera and the Test folder for sync
5. Add the photo to a Shared Album
6. When the Shared Album is viewed on the device where the photo/albums are present, the picture will be shown n times, n being the number of albums it exists in and with drifting metadata.

• Manually verified on a Pixel 9 Pro (via flutter run over ADB) side-to-side with current Play Store version. Duplicate assets are no longer shown in Shared Album view.
• flutter test - All 668 tests pass (with 1 skipped)

Checklist:

• I have carefully read CONTRIBUTING.md
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary. (N/A, no new deps)
• I have written tests for new code (if applicable) (N/A - bug fix, covered by existing suite)
• I have followed naming conventions/patterns in the surrounding code
• [ ] All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc. N/A, change effects /mobile only
• [ ] All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/) N/A, change effects /mobile only

Please describe to which degree, if any, an LLM was used in creating this pull request.

N/A

[shenlong-tanwen]

@stfn42 Hey, Thanks a lot for the fix. This re-creates a de-duplicated view for joining for every method call, which happens quite often when scrolling the timeline. Rather, it might be best to use corelated subqueries like the main timeline. Can you update the fix to use them instead?

[stfn42]

@shenlong-tanwen Yeah, that's good feedback, thanks. Updated version uses same approach as merged_asset.drift. PTAL :).

[stfn42]

Fixed dart formatting