feat(mobile): optimize remote image request pipeline with fast-path on ios

[LeLunZ]

Description

Early returns a remote image request without scheduling a new operation if an encoded image was requested.

Previously if a remote image was requested, and flutter requested the encoded version we launched another thread (from the request background thread) just to return a copy of some data.
I think in such a case it doesn't really make sense to wait on an available thread. The copy is just a memory operation, and nothing cpu intensive for which we would need a new thread.

How Has This Been Tested?

@mertalev Does this need some testing? Currently we only use that for animated images in the asset viewer, so I can't even do the timeline fast scrolling tests, or some automated fast scrolling tests.

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.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

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