Refuse a size whose computed side exceeds the maximum (closes #241)

A side given as 0 is computed from the source's proportions, and
nothing held it to 8192: 0x8192 of a 3000x600 source was resized to
40960x8192 and encoded. Process now refuses such a size with
ErrOutputTooLarge once it knows the source's dimensions, before the
resize and the encode, and both image routes answer it 400 with the
JSON error body. It is a processing error, not a failed fetch, so it
is never negative-cached. imgcache.MaxDimension is now
imageprocessor.MaxOutputDimension, so the request limit and the output
limit are one value. README.md says it under Routes and Encrypted URLs.

Model: opus-5-5

README.md

@@ -263,6 +263,10 @@ once, is refused with 400.
   both optional (values under Signature Specification). Both are part of what is
   cached, so each value of either is a separate cached image.
 
+A size with one side `0` has that side scaled to keep the source's proportions,
+and is refused with 400 when that side would come out above 8192, the most
+either side may be.
+
 The source image may be JPEG, PNG, GIF, WebP, AVIF or JPEG XL. The upstream's
 `Content-Type` must name its format, and the image's first bytes must match it.
 An upstream answering with any other `Content-Type`, SVG included, is refused
@@ -345,7 +349,8 @@ nor change what it asks for.
    (`POST /generate`). The format is JPEG XL unless another is chosen; a form
    sent with an empty format, or none, also makes a JPEG XL URL. Width and
    height both empty or `0` keep the original size; if only one of them is empty
-   or `0`, that side is scaled to keep the image's proportions.
+   or `0`, that side is scaled to keep the image's proportions. A URL whose
+   scaled side would come out above 8192 answers 400.
 3. The page shows the URL, `https://<host>/v1/e/<token>/img.<format>`, and when
    it expires. `<host>` is the host the page was opened on, and the URL starts
    with `http` instead while `debug` is on. The name after the token is ignored