feat(backend): harden Admin Dashboard Service — rate limiting, signature verification, SQL optimization, error recovery

[Akanimoh12]

Summary

This PR hardens the Admin Dashboard Service (the /api/metrics/* revenue/volume reporting endpoints and their backing metricService) across four areas: rate limiting, request signature verification, SQL query efficiency, and DB error recovery.

• Rate limiting ([Backend] Implement rate limiting for Admin Dashboard Service #927): Added createDashboardMetricsRateLimit / getDashboardMetricsRateLimitKey in lib/rate-limit.js, following the same per-merchant (falling back to hashed API key, then IP) keying pattern already used for merchant security actions and SEP-10 endpoints. Wired into /api/metrics/summary, /api/metrics/revenue, and /api/metrics/volume via a Redis-backed store when Redis is available, matching the existing wiring in app.js.
• Signature verification ([Backend] Add cryptographic signature verification to Admin Dashboard Service #928): All three dashboard routes now require requireApiKeyAuth({ requireSignature: true }), enforcing the existing HMAC x-api-signature / x-api-timestamp request-signing scheme (already used by sensitive merchant routes) instead of relying on the API key alone.
• SQL optimization ([Backend] Optimize SQL queries in Admin Dashboard Service #929):
  • Fixed a missing metricService import in routes/metrics.js — the route referenced metricService without importing it, which meant /api/metrics/summary and /api/metrics/revenue would throw a ReferenceError on every request.
  • Removed a duplicated inline SQL query in the /api/metrics/volume handler that re-implemented metricService.getVolumeOverTime instead of calling it.
  • Merged the two sequential last-month/current-month queries in metricService.getMonthlySummary into a single query using conditional aggregation (FILTER (WHERE ...)), halving the DB round trips for that endpoint while still using the existing (merchant_id, status, created_at) index.
• Error recovery ([Backend] Enhance error recovery for Admin Dashboard Service #930): All metricService DB calls now go through retry-with-backoff and the shared circuit breaker from lib/db.js (the same circuit breaker already protecting auth and audit-log writes), so transient connection errors are retried instead of surfacing as hard failures to the dashboard.

Also converted routes/metrics.js from a static router export to a createMetricsRouter factory so the rate limiter can be injected, matching the existing factory pattern used by routes/payments.js and routes/merchants.js.

Test plan

• Added lib/rate-limit.test.js coverage for createDashboardMetricsRateLimit / getDashboardMetricsRateLimitKey
• Added services/metricService.test.js covering the combined summary query, zero-activity asset filtering, retry-then-succeed, and non-retryable failure paths
• Added routes/metrics.test.js covering signature enforcement, rate-limit rejection (429), and successful delegation to metricService for all three routes
• Maintainer to run full CI (npm test in backend/) to confirm no regressions

Closes #927
Closes #928
Closes #929
Closes #930

[vercel]

@Akanimoh12 is attempting to deploy a commit to the Emmanuel's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@Akanimoh12 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