fix: read EXIF orientation directly for plain file paths

[dcalhoun]

Description

ImageUtils.getImageOrientation prefixes any non-content:// path with content://media and queries the MediaStore content provider first, only falling back to reading EXIF when that query returns nothing.

For a plain filesystem path pointing at an existing file (e.g. an app cache file), that constructed Uri is never resolvable through MediaStore, so the query always fails. On some devices it fails by throwing IllegalArgumentException: Volume data not found, which is caught but logged as an error with a full stack trace on every call:

E  Error reading orientation of the file: /data/user/0/<app>/cache/.../image.jpg
   java.lang.IllegalArgumentException: Volume data not found
       at android.database.DatabaseUtils.readExceptionFromParcel(...)
       ...
       at org.wordpress.android.util.ImageUtils.getImageOrientation(ImageUtils.java:100)
       at org.wordpress.android.util.ImageUtils.optimizeImage(ImageUtils.java:547)

The orientation was still resolved correctly (via the EXIF fallback), so this was benign but noisy — and increasingly common now that hosts optimize images staged in their own cache directories (e.g. GutenbergKit's native media upload processing).

Fix

When the path is a plain filesystem path that points at an existing file, read EXIF orientation directly and skip the doomed provider query. EXIF is the only orientation source such a file has, so this is behavior-preserving. MediaStore-style paths (which don't exist on the filesystem) keep the previous query-then-EXIF-fallback behavior.

Testing

Verified in a host app (wordpress-mobile/WordPress-Android#23142) that optimizes an image staged in its cache dir: before this change the error + stack trace logged on every upload; after, it's gone and orientation is still applied correctly.

Co-authored with Claude.

[nbradbury]

@dcalhoun Claude found one issue that you may or may not want to address:

Percent-encoded file:// URIs still fall through. file:///storage/emulated/0/My%20Photo.jpg → after the scheme strip, File("/storage/.../My%20Photo.jpg").exists() is false, so it still takes the old failing-query path and logs the error. Not a regression, but the fix doesn’t cover it. Decoding with Uri.decode() before the File check would close that gap if you’re seeing it in the wild.

[dcalhoun]

@nbradbury I addressed the feedback comment and retested. I believe this ready for another review.

[nbradbury]

Looks good!