Give the slowest AVIF encode at the limit across quality

The AVIF times given before, 25 seconds with an alpha channel and 15
without, came from quality 85 and 100 only. Measured again with the
runtime image's libvips on one thread at qualities 1 to 100, 4096x4096,
8192x2048 and 2048x8192 random pixels take up to about 34 seconds with
an alpha channel and 22 without, the slowest at quality 90 to 99. That
is under 40, so the limit stays at 16,777,216 pixels. The doc comments,
README.md and TODO.md now give those times. WebP and JPEG XL, measured
the same way, stay within the times already given, which now say they
hold at any quality. The TODO.md entry moves to the top of Completed
Steps.

Model: opus-5-5

README.md

@@ -397,11 +397,12 @@ takes up to about 1 second as JPEG, 15 as PNG and 16 as GIF, the slowest of 8 or
 16 bits per sample, with or without an alpha channel. The WebP and JPEG XL
 encoders run below libvips' default effort, and AVIF at the lowest effort govips
 can set, so that no encode takes more than 40 seconds of the default
-`downstream_timeout` of 60: at quality 85 or 100 and 8 or 16 bits per sample,
+`downstream_timeout` of 60: at any quality and 8 or 16 bits per sample,
 8192x8192 random pixels with an alpha channel take up to about 23 seconds as
-WebP and 27 as JPEG XL, and 4096x4096 or 8192x2048 up to about 25 as AVIF, which
-would take about 99 at 8192x8192. Without an alpha channel they take up to about
-16, 13 and 15 seconds. Decoding such a source adds up to about 11 seconds.
+WebP and 27 as JPEG XL, and 4096x4096, 8192x2048 or 2048x8192 up to about 34 as
+AVIF, which at quality 85 would take about 96 at 8192x8192. Without an alpha
+channel they take up to about 16, 13 and 22 seconds. Decoding such a source adds
+up to about 11 seconds.
 
 The login form (`POST /`) is limited to 5 attempts per minute per client
 address, counting an IPv6 client by its /64; an attempt over the limit is