web: export a big photo without inventing pixels it already has

The export menu measured the photo off the 1600px preview copy, so a 2400px
photo was believed to be 1600px across: the hint named the wrong size, the
model was asked to upscale a photo that already had more pixels than the
target, and a guest's 2048 ceiling was skipped because 1600 never crossed it.
A committed crop made it worse — the crop's longest edge was taken from the
wider side of the crop rect rather than the side the frame actually keeps, so
a 2400x1800 photo with the default 0.8 frame was called 1280px and ran the
model over 80 tiles (158.7s) to reach 2K.

The photo's own dimensions are now read off the original bytes, and the crop's
long edge is the same axis-aware fraction the stage already uses. The export
asks the model only when the photo itself is short of the requested size, or
when the crop would have to be stretched past 1.5x to get there; otherwise it
resamples — down, or a hair up to make up for the crop — which is what a photo
that already holds the pixels deserves.

Measured, wasm path, 2400x1800: no crop at 2K went 2.7s/2400px (wrong size) to
3.4s/2048px, the default 0.8 crop went 158.7s/80 tiles to 3.5s/no model, and a
1:1 crop went 2.5s/1800px to 4.0s/2048px. A 1200x900 photo cropped to 1:1 and
exported at 2K still runs the model (2048 from a 900px crop, 40.3s), and the
superres suite is unchanged: 640x480 to 2K/4K/custom still comes out exact,
with the model's 16.6 edge energy against bilinear's 4.8.

docker/frontend/src/engine/imageOps.ts

@@ -31,6 +31,32 @@ export async function resizedJpeg(bytes: Uint8Array, maxDim: number, quality = 0
   }
 }
 
+// The same resample, but it enlarges as well as shrinks and always re-encodes.
+// `resizedJpeg` refuses to grow a photo back, which is right for the preview
+// copy; the export needs the growth because a committed crop keeps only part of
+// the photo, so the whole photo has to be stretched a little for the crop to
+// land on the requested size — and a plain filter is the honest answer when the
+// photo already holds those pixels. Only ever called with a target the photo
+// already covers (see the export's gain guard).
+export async function scaledJpeg(bytes: Uint8Array, targetLongest: number, quality = 0.95): Promise<Uint8Array> {
+  const bitmap = await createImageBitmap(new Blob([bytes as BlobPart]));
+  try {
+    const longest = Math.max(bitmap.width, bitmap.height);
+    if (longest === targetLongest) return bytes;
+    const scale = targetLongest / longest;
+    const w = Math.max(1, Math.round(bitmap.width * scale));
+    const h = Math.max(1, Math.round(bitmap.height * scale));
+    const canvas = new OffscreenCanvas(w, h);
+    const ctx = canvas.getContext('2d');
+    if (!ctx) return bytes;
+    ctx.drawImage(bitmap, 0, 0, w, h);
+    const blob = await canvas.convertToBlob({ type: 'image/jpeg', quality });
+    return new Uint8Array(await blob.arrayBuffer());
+  } finally {
+    bitmap.close();
+  }
+}
+
 // The colour under one point of a photo, for the HSL mixer's eyedropper.
 // `fx`/`fy` are fractions of the photo (0..1, from the click position over the
 // <img>), so the caller needs no knowledge of the stage's zoom, pan or box.