X-Request-ID silently missing from every response

The README advertises "every response carries X-Request-ID... so a single request's full retry/idempotency journey is traceable from one log grep." With the header silently dropped, a support engineer handed a customer-reported error has no correlation ID to grep server logs for -- they either have to reconstruct the request from timestamps and hope nothing else happened in that window, or ask the customer to reproduce the issue again. For an on-call engineer during an incident, that's the difference between finding the exact failing request in seconds versus minutes of log spelunking.

RequestIDMiddleware is supposed to set the X-Request-ID response header before the handler writes its response. It now calls the next handler first and sets the header afterward -- by which point the handler has already sent the status line (via w.WriteHeader, called inside writeJSON/writeError/writeStoredResponse), and a real HTTP server silently ignores header mutations made after that point.

go run ./cmd/server & curl -i localhost:8080/healthz | grep -i x-request-id

got: (nothing)

want: X-Request-ID: <32 hex chars>

Note: httptest.NewRecorder() will NOT reproduce this -- see the note in test/README.md about why task08_test.go uses a real listener instead.

This is a real, easy-to-make Go HTTP gotcha: header mutations are only honored before the first Write/WriteHeader call on a ResponseWriter. Once the status line has gone out, further w.Header().Set(...) calls are silently no-ops on a real connection -- not an error, not a panic, just quietly ignored, which is exactly why this class of bug is easy to introduce during a refactor and easy to miss in testing that doesn't use a real transport.

Look at the order of the three statements inside RequestIDMiddleware's handler closure: generating/reading the ID, calling next.ServeHTTP, and setting the response header. Compare that order to LoggingMiddleware right below it in the same file, which correctly reads response state (via statusWriter) only after next.ServeHTTP returns -- but critically never needs to write anything to the response after that point, which is the difference that matters here.