docs(photo): the 1024px bound is on the shortest edge, not the longest (#1001)

Three comments claimed `minWidth`/`minHeight` cap the longest edge. They bound
the shortest one. flutter_image_compress takes
`max(1, min(width/minWidth, height/minHeight))` as its scale factor
(BitmapCompressExt.kt:62-66; UIImage+scale.m:12-21 picks the same branch), so
the smaller ratio wins and the edge landing on 1024 is the short one. A
4080x3072 camera frame comes out 1360x1024, not 1024x768 -- about 1.8x the
pixels the comments promised, and more again at 16:9.

Comments only; the calls are unchanged and the behaviour was always this.
Corrected in meal_photo_encoder.dart and user_image_storage.dart, where the
claim appeared twice each (dartdoc summary and the call site), and in
recipe_builder_screen.dart, which repeated it when explaining why it picks at
full resolution.

Found while checking docs/ai-architecture.md, which stated the same thing and
is corrected in #996.

(cherry picked from commit 202a21b)

Author: simonoppowa

lib/core/utils/user_image_storage.dart

@@ -31,8 +31,8 @@ enum UserImageKind {
 /// across app reinstalls and iOS sandbox refreshes, where the documents
 /// directory's parent prefix can change between launches.
 ///
-/// Photos are stored as WebP at quality 80, capped at 1024px on the
-/// longest edge — small enough that an export zip of a few dozen
+/// Photos are stored as WebP at quality 80, bounded at 1024px on the
+/// shortest edge — small enough that an export zip of a few dozen
 /// recipes and meals stays in the low-megabyte range, while still
 /// being plenty crisp for a list thumbnail and the detail-screen
 /// header. WebP roughly halves the bytes of an equivalent-quality JPEG
@@ -83,7 +83,7 @@ class UserImageStorage {
     return imagesDir;
   }
 
-  /// Reads `sourcePath`, re-encodes it to WebP (quality 80, longest
+  /// Reads `sourcePath`, re-encodes it to WebP (quality 80, shortest
   /// edge 1024px), writes the result to the matching images directory
   /// under `<ownerId>.webp`, and returns the relative slug to persist.
   /// The source file is left untouched.
@@ -185,9 +185,12 @@ class UserImageStorage {
         quality: 80,
         minWidth: 1024,
         minHeight: 1024,
-        // `minWidth`/`minHeight` are upper bounds for the *longest*
-        // edge when the source exceeds them; the compressor preserves
-        // aspect ratio. Shorter-edge images pass through untouched.
+        // `minWidth`/`minHeight` bound the *shortest* edge, not the longest.
+        // The compressor takes `min(width/minWidth, height/minHeight)` as its
+        // scale factor, so the smaller ratio wins and the edge that lands on
+        // 1024 is the short one: a 4080x3072 frame comes out 1360x1024, and a
+        // 16:9 frame wider still. Aspect ratio is preserved and an image
+        // already smaller than 1024 on both edges passes through untouched.
       );
     } catch (_) {
       return null;

lib/features/add_meal/util/meal_photo_encoder.dart

@@ -53,7 +53,7 @@ enum MealPhotoFormat {
 /// the documents directory is a photo the export zip picks up and the user
 /// never asked to keep.
 ///
-/// The encoding — quality 80, longest edge 1024 px — matches
+/// The encoding — quality 80, shortest edge 1024 px — matches
 /// `UserImageStorage` on purpose. It is the pipeline this app already trusts
 /// for food photography, and a 1024 px image is about 1400 visual tokens,
 /// which is what makes this cost fractions of a cent where anyone is charging
@@ -193,9 +193,12 @@ class MealPhotoEncoder {
         // the app promises it asks for no location. [PhotoMetadata] does the
         // same job on the fallback path below, where no encoder runs.
         keepExif: false,
-        // `minWidth`/`minHeight` are upper bounds for the *longest* edge
-        // when the source exceeds them; the compressor preserves aspect
-        // ratio. Shorter-edge images pass through untouched.
+        // `minWidth`/`minHeight` bound the *shortest* edge, not the longest.
+        // The compressor takes `min(width/minWidth, height/minHeight)` as its
+        // scale factor, so the smaller ratio wins and the edge that lands on
+        // 1024 is the short one: a 4080x3072 frame comes out 1360x1024, and a
+        // 16:9 frame wider still. Aspect ratio is preserved and an image
+        // already smaller than 1024 on both edges passes through untouched.
       );
     } catch (_) {
       return null;

lib/features/recipes/presentation/screens/recipe_builder_screen.dart

@@ -408,8 +408,8 @@ class _RecipeBuilderScreenState extends State<RecipeBuilderScreen> {
     try {
       final picker = ImagePicker();
       // Pick at full resolution — `UserImageStorage.importFrom` re-encodes
-      // to WebP at quality 80 with a 1024px longest-edge cap, so we don't
-      // need image_picker's own JPEG compression on top. Doing it in one
+      // to WebP at quality 80, bounding the shortest edge at 1024px, so we
+      // don't need image_picker's own JPEG compression on top. Doing it in one
       // place keeps the on-disk footprint consistent regardless of which
       // source (camera / gallery) the photo came from.
       final picked = await picker.pickImage(source: source);