feat: correlation IDs, error reporting and trade audit visibility (#81)

[zeemscript]

Summary

Closes #81

• Generate x-request-id per request (honors client-sent IDs), echo in response header, and bind to Pino logger so every log line includes request_id
• Include request_id and short support_code (e.g. 3f2a-bc91) in all error responses (global error handler + auth middleware)
• Add POST /client-errors endpoint for APK crash/error reporting (auth optional)
• Thread request_id into audit log entries for all trade state transitions; add GET /audit/lookup?request_id= for support search
• Frontend: ErrorBoundary displays "Código de soporte" on crashes and auto-reports to backend; API errors show support code inline

Files changed

Backend (new): requestId.middleware.ts, client-errors.ts, requestId.test.ts
Backend (modified): index.ts, auth.middleware.ts, audit-log.model.ts, trade.service.ts, trades.ts
Frontend (new): reportError.ts
Frontend (modified): apiError.ts, ErrorBoundary.tsx, CancelTradeDialog.tsx, api.ts
Migrations: audit_log.request_id, client_errors table

Test plan

• Unit tests pass (requestId.test.ts, rateLimit.test.ts)
• x-request-id header echoed on all responses (success + error)
• Client-provided x-request-id honored, not overwritten
• Error JSON includes request_id + support_code (auth errors, validation errors, app errors)
• POST /client-errors accepts reports with/without auth
• request_id appears in structured backend logs
• Trigger a backend error from the APK and verify support code is visible to the user

[drips-wave]

@zeemscript Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits