fix: read EXIF orientation directly for plain file paths

getImageOrientation prefixed non-content paths with "content://media"
and queried the MediaStore content provider first, falling back to EXIF
when that failed. For a plain filesystem path pointing at an existing
file (e.g. an app cache file), that constructed Uri is never resolvable
and the query always fails — on some devices by throwing
IllegalArgumentException ("Volume data not found"), which was logged
as an error with a stack trace on every call.

Such files carry their orientation only in EXIF, so read it directly
and skip the doomed provider query. MediaStore-style paths (which do
not exist on the filesystem) keep the previous behavior.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: dcalhoun

WordPressUtils/src/main/java/org/wordpress/android/util/ImageUtils.java

@@ -90,6 +90,14 @@ public static int getImageOrientation(Context ctx, String filePath) {
         filePath = filePath.replace("file://", "");
 
         if (!filePath.contains("content://")) {
+            // A plain filesystem path pointing at an existing file (e.g. an app cache file) is not
+            // resolvable through the MediaStore content provider — prefixing it with
+            // "content://media" would produce a bogus Uri whose query always fails (throwing on
+            // some devices). EXIF is the only orientation source such a file has, so read it
+            // directly.
+            if (new File(filePath).exists()) {
+                return getExifOrientation(filePath);
+            }
             curStream = Uri.parse("content://media" + filePath);
         } else {
             curStream = Uri.parse(filePath);