Include the request id in `middleware/errorHandler.ts`'s JSON error envelope for support/debugging correlation

[Jagadeeshftw]

📌 Description

middleware/requestId.ts sets x-request-id on every response header, and middleware/auditLog.ts records it for mutating requests, but middleware/errorHandler.ts's JSON error envelope ({ error: { code, message } }) doesn't include it. A client reporting an error to support has to separately dig the id out of response headers instead of getting it directly in the error body they're likely already logging.

🧩 Requirements and context

• Add a requestId field to the { error: { code, message, requestId } } envelope produced by errorHandler, sourced from the already-set x-request-id response header.
• Apply this to all three response branches in errorHandler (ApiError, body-parser 4xx, and the 500 fallback).
• Keep the field optional/undefined-safe in case requestId middleware isn't mounted in some future minimal setup.

🛠️ Suggested execution

• Modify src/middleware/errorHandler.ts to read res.getHeader("x-request-id") and include it in every JSON error response.
• Update src/openapi.ts or any documented error-shape reference to mention the new field.
• Add tests in src/middleware/errorHandler.test.ts asserting requestId is present and matches the response header for each of the three error branches.

✅ Acceptance criteria

• Every JSON error response includes a requestId field matching the x-request-id response header.
• All three errorHandler branches (ApiError, body-parser 4xx, 500 fallback) include it.
• Existing errorHandler.test.ts assertions on code/message still pass with the added field present.

🔒 Security notes

N/A — surfaces an already-public header value inside the error body for easier support correlation; no new information disclosed.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours