Add request-ID correlation

Every minute spent by support or on-call trying to figure out which server-side log line matches this customer's complaint is a minute the customer is waiting for an answer, and a minute of engineering time spent on detective work instead of a fix. Without request-ID correlation, that matching is done by eyeballing timestamps and hoping nothing else happened in the same window -- it gets actively worse as traffic grows, right when you can least afford slow incident response. This is usually one of the first things a customer-facing API is missing before it's ready to handle real support load, and it directly affects how fast SLA-bound issues get resolved.

logRequests in internal/api/router.go logs method, path, status, and duration per request via log/slog. There is no way to correlate a single client-visible failure (say, a 429 a user reports) with the exact server log line for that request -- if two requests to the same path fail around the same time, the logs are indistinguishable, and the client has no token to hand back to support/on-call.

curl -i localhost:8080/healthz | grep -i x-request-id // got: (nothing) // want: X-Request-ID: <some unique value>

This is the single most common "day one" observability gap in a service: without it, connecting a user's bug report to server-side logs means grepping by timestamp and hoping nothing else happened in that window.

Add the ID-generation and header-echoing as its own middleware (a function with the same func(http.Handler) http.Handler shape as logRequests), so it composes the same way in Router(). Order matters: it needs to run before logRequests reads/sets anything it depends on, and before the mux dispatches to a real handler if you want handlers to be able to read it from r.Context(). Use an unexported context-key type (not a bare string) to avoid collisions with other packages' context values.