X-Request-Id is the same hardcoded value on every response

A request ID is only useful for tracing/correlation if it is actually unique per request -- "every request gets the label stub-request-id" is equivalent to not having request IDs at all for debugging purposes (searching logs for it returns everything, which is the same as searching for nothing). And silently overwriting a client-supplied ID breaks any correlation the client was already trying to do across its own systems and this gateway.

Every successful proxied response already includes an X-Request-Id header -- the wiring in app/routers/proxy.py is done. But get_or_create_request_id() is a stub: it always returns the literal string "stub-request-id", regardless of the request.

1. pytest practice_tickets/tests/test_ticket_12_request_id_propagation.py -v.
2. Or manually: send two requests through the gateway with no X-Request-Id header, and one with an explicit X-Request-Id.
3. Observe: all three responses come back with the same "stub-request-id" value.

get_or_create_request_id(request) already receives the Request -- it has everything it needs (the incoming headers, to check for an existing X-Request-Id; the standard library, to generate one when there is not) but its body never looks at any of that, returning a constant instead.

Read the incoming X-Request-Id header off request.headers first; fall back to generating a fresh id (e.g. uuid.uuid4()) only when it is missing. Forwarding this ID upstream too, and correlating it into the latency/breaker metrics, would be natural follow-ups but are out of scope here -- this ticket is scoped to what the response header reports.