Serve both image routes with one function and one error mapping (closes #316)

HandleImage parses the path and verifies the signature, and HandleImageEnc
decrypts the token. Each then calls serveImage, which chooses the format for
auto, gets the image and serves it: the headers, ETag and 304, HEAD, the copy
and the log line. respondImageError answers the image service's errors on both
routes, and handleImageError is gone. /v1/image/ now answers 504 when the
upstream sends no response headers within upstream_fetch_timeout, as README.md
documented for /v1/e/. respondImageError logs a 500 at error level and every
other answer at warn. A failed write is logged once, with the request and the
bytes served. README.md lists each image route's answers as bullets. Tests send
the same errors through both routes.

Model: opus-5-5

TODO.md

@@ -30,6 +30,33 @@ P2: security: per-origin rate limiting
 
 # Completed Steps
 
+- 2026-10-26 both image routes serve an image with one function, `serveImage`,
+  and answer its errors with one, `respondImageError` (closes #316).
+  `HandleImage` parses the path and verifies the signature, and `HandleImageEnc`
+  decrypts the token. Each then calls `serveImage`.
+    - `handleImageError`, the encrypted route's own mapping, is gone.
+    - `/v1/image/` answers 504 when the upstream has not sent its response
+      headers within `upstream_fetch_timeout`, as `/v1/e/` did. It answered 500.
+    - `respondImageError` logs the image service's errors as "failed to get
+      image". Each answer gets the same level on `/v1/image/` and on `/v1/e/`:
+        - 500: error, as pixa's own failure
+        - 400: warn
+        - 403: warn
+        - 415: warn
+        - 502: warn
+        - 503: warn
+        - 504: warn
+    - Before, `/v1/image/` logged all of these answers at error level. `/v1/e/`
+      logged only its 500, as "image request failed", without the host and the
+      path.
+    - `respondImageError` does not log the 415 for a body refused for its first
+      bytes, on either route. The image service logs it as "source refused", at
+      warn level.
+    - The "image served" line carries the host, the path and `fetched_bytes` on
+      both routes. The debug line "encrypted image request" is gone.
+    - A failed write is logged once, as "failed to write response" at error
+      level. It carries the `request_id`, the host, the path, `served_bytes` and
+      the error, and is not also logged as "image served".
 - 2026-10-26 every key derived from the signing key is derived in one place
   (closes #315): `seal.DeriveKeys` returns them as one `seal.Keys`, with their
   salts declared beside it. `internal/providers` calls it once at startup. Each