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

README.md

@@ -139,12 +139,13 @@ path under `/v1/` answers 200, in maintenance mode too.
   401 without them; 404 when they are not set, as the route then does not exist.
 
 Every response carries an `X-Request-ID` header holding the request's ID, which
-a client can quote when reporting a problem: the request's own `X-Request-ID`
-when it sent one, as a reverse proxy in front of pixa may, otherwise one pixa
-makes up from its host name, a random string chosen at startup and a counter.
-pixa's log line for the request carries the same ID as `request_id`, and so do
-the lines it logs when it fetches, converts and serves an image; the fetch sends
-it to the upstream host as `X-Request-ID`.
+a client can quote when reporting a problem: the request's own `X-Request-ID`,
+as a reverse proxy in front of pixa may send, when it is at most 64 letters,
+digits, `-`, `_` or `.`; otherwise a random one pixa makes for the request,
+which tells nothing about the machine or the other requests. pixa's log line for
+the request carries the same ID as `request_id`, and so do the lines it logs
+when it fetches, converts and serves an image; the fetch sends it to the
+upstream host as `X-Request-ID`.
 
 Both `POST` routes accept only a form that pixa's own page served: the page puts
 a token in the form and sets a cookie to match, and a request without both is