Keep only a short, plain request ID; make others up at random

pixa's own RequestID middleware replaces chi's and the response-header
middleware. It keeps a request's own X-Request-Id only when it is at
most 64 letters, digits, '-', '_' or '.', so an over-long or odd value
is never sent back or upstream, and otherwise makes a random ID with
crypto/rand, which tells nothing about the host or how many requests
pixa served. It stores the ID under chi's RequestIDKey, where the
logging middleware, the handlers and the fetcher read it.

Model: opus-5-5

TODO.md

@@ -30,9 +30,10 @@ P2: security: referer blacklist
 # Completed Steps
 
 - 2026-10-04 request IDs returned and passed on, and `/v1/e/` revalidates
-  (closes #84): a middleware right after chi's `RequestID` sets `X-Request-ID`
-  on every response from the ID `RequestID` stores in the request context, which
-  is the request's own `X-Request-ID` when it sent one; the upstream fetch sends
+  (closes #84): pixa's own `RequestID` middleware, in place of chi's, gives each
+  request an ID, its own `X-Request-ID` when that is at most 64 letters, digits,
+  `-`, `_` or `.` and a random one otherwise, stores it where chi's did and
+  sends it back as `X-Request-ID` on every response; the upstream fetch sends
   that ID, and the "upstream fetched", "image converted" and "image served" log
   lines carry it as `request_id`, a fetch shared by several requests carrying
   the first request's; `/v1/e/` sets `ETag`, answers a matching `If-None-Match`