Keep each side at 1 or more with fit=outside too

fit=outside works both sides out again from the larger scale, and a side
scaled to 1 could come out just under 1 and round down to 0, which
libvips refuses: a 49x8192 source at 0x100 and a 49x49 source at 1x1
answered 500. README.md now says what fit=outside does, with the 8192x1
source at 100x0 that comes out at 8192x1, and how a 0 side is worked
out from the source's proportions.

Model: opus-5-5

TODO.md

@@ -30,6 +30,20 @@ P2: security: per-origin rate limiting
 
 # Completed Steps
 
+- 2026-10-16 a size with one side `0` keeps the side computed from the source's
+  proportions at 1 or more (closes #283): it was rounded down, so for a thin
+  source it came out at 0, and libvips then made the size square. An 8192x1
+  source at `100x0` came out at 100x100, and at `1300x0` with `fit=cover` made
+  libvips ask for about 39 GB at once; an 8192x2 source at `100x0` answered 500.
+  `fit=contain` and `fit=inside` work both sides out again from the smaller of
+  the two scales and `fit=outside` from the larger, and each keeps both sides at
+  1 or more too, so a 1x8192 source at `0x100` with `fit=contain`, and a 49x8192
+  source at `0x100` or a 49x49 source at `1x1` with `fit=outside`, no longer
+  answer 500. An 8192x1 source at `1300x0` now comes out at 1300x1, and the
+  process running it alone peaked at about 34 MiB resident. With `fit=outside`
+  the image is scaled to cover the size, so that source at `100x0` comes out at
+  8192x1. `README.md` now says this under Signature Specification, and says how
+  a `0` side is worked out where it said `0` meant the original.
 - 2026-10-16 the source URL a request fetches is built with `net/url` from the
   source host, path and query, not joined as text (closes #288). The source
   path, decoded, is fetched percent-encoded again, so `100%25.png` fetches
@@ -43,17 +57,6 @@ P2: security: per-origin rate limiting
   another way, such as with `%2F` in the path, whatever else the path holds, or
   with a user name and password. It also answers 400 for a source path holding a
   `..` segment, as `/v1/image/` refuses one.
-- 2026-10-16 a size with one side `0` keeps the side computed from the source's
-  proportions at 1 or more (closes #283): it was rounded down, so for a thin
-  source it came out at 0, and libvips then made the size square. An 8192x1
-  source at `100x0` came out at 100x100, and at `1300x0` with `fit=cover` made
-  libvips ask for about 39 GB at once; an 8192x2 source at `100x0` answered 500.
-  `fit=contain` and `fit=inside` work both sides out again from the smaller of
-  the two scales, and keep each at 1 or more too, so a 1x8192 source at `0x100`
-  no longer answers 500 there. An 8192x1 source at `1300x0` now comes out at
-  1300x1, and the process running it alone peaked at about 34 MiB resident. With
-  `fit=outside` the image is scaled to cover the size, so that source at `100x0`
-  comes out at 8192x1.
 - 2026-10-15 a thin source requested with `fit=cover` no longer makes libvips
   build a huge image (closes #282): libvips' thumbnail scaled the whole source
   to cover the requested size and copied that into memory before it cut out the