Answer 503 to a request waiting on a transcode stopped at a deadline

A request that waited for another request's transcode got that
request's deadline error when the transcode stopped at its deadline,
and both image routes answered it 500, though the waiting request's
own downstream_timeout had time left. The image service now returns
ErrProcessingTimedOut for it, which both routes answer 503 "server
busy, try again later", as when pixa is busy. README.md "Routes" says
so.

Model: opus-5-5

README.md

@@ -319,18 +319,20 @@ fetch sends the first request's ID upstream, and the lines logged for the fetch
 and the transcode carry that ID.
 
 A transcode whose request's `downstream_timeout` has ended (for a shared one,
-the first request's) stops when it gets its processing slot or before it begins
-encoding, and gives the slot back. libvips cannot stop an encode once it has
-begun, so an encode keeps its slot until it finishes, which can be after
-`downstream_timeout`. The limit of 8192 on each side of the source and of the
-output bounds how long that takes. With one libvips thread, as pixad runs it,
-encoding 8192x8192 random pixels takes up to about 1 second as JPEG, 15 as PNG,
-16 as GIF, 63 as WebP, 110 as AVIF and 96 as JPEG XL, the slowest of 8 or 16
-bits per sample, with or without an alpha channel. WebP, AVIF and JPEG XL are
-that slow only with an alpha channel: 8-bit RGB takes about 44, 53 and 28
-seconds. Decoding such a source adds up to about 11 seconds. A WebP, AVIF or
-JPEG XL encode can therefore hold its slot past the default `downstream_timeout`
-of 60 seconds.
+the first request's) stops waiting for a processing slot, or, once it has one,
+gives it back without beginning to encode. A request waiting for a shared
+transcode that stops this way is answered 503 with the error
+`server busy, try again later`, though its own `downstream_timeout` may not have
+ended. libvips cannot stop an encode once it has begun, so an encode keeps its
+slot until it finishes, which can be after `downstream_timeout`. The limit of
+8192 on each side of the source and of the output bounds how long that takes.
+With one libvips thread, as pixad runs it, encoding 8192x8192 random pixels
+takes up to about 1 second as JPEG, 15 as PNG, 16 as GIF, 63 as WebP, 110 as
+AVIF and 96 as JPEG XL, the slowest of 8 or 16 bits per sample, with or without
+an alpha channel. WebP, AVIF and JPEG XL are that slow only with an alpha
+channel: 8-bit RGB takes about 44, 53 and 28 seconds. Decoding such a source
+adds up to about 11 seconds. A WebP, AVIF or JPEG XL encode can therefore hold
+its slot past the default `downstream_timeout` of 60 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