feat(#593): Add comprehensive Prometheus metrics collection

[amankoli09]

Closes #593

Summary

• Expose GET /metrics endpoint via PrometheusController with optional bearer-token authentication (METRICS_AUTH_TOKEN env var)
• Add HttpMetricsMiddleware to auto-record HTTP request durations and 5xx error counts with cardinality-safe route normalisation
• Add DbMetricsSubscriber (TypeORM EntitySubscriber) to record per-query execution times into db_query_duration_seconds histogram
• Add DbPoolMetricsCollector (scheduled every 10 s) to push pg pool stats (size, idle, pending, active) into Prometheus gauges
• Enhance MetricsCollectionService with full metric set:
  • Infrastructure: http_request_duration_seconds, db_query_duration_seconds, db_active_connections, db_pool_size / idle / pending / acquired / released
  • Business: user_registrations_total, active_users, course_enrollments_total, course_completion_rate_percentage, assessment_completions_total, learning_path_progress_percentage, payment_transactions_total, cache_hit_rate_percentage, queue_processing_duration_seconds, email_campaigns_sent_total, backup_operations_total, api_errors_total
• Wire all new providers and controller into MonitoringModule
• Document METRICS_ENABLED / METRICS_AUTH_TOKEN / METRICS_PATH in .env.example
• Add 16 unit tests (prometheus.controller.spec.ts, http-metrics.middleware.spec.ts) – all passing

Type of change

• ✨ New feature (non-breaking change that adds functionality)
• 🐛 Bug fix (non-breaking change that fixes an issue)
• 💥 Breaking change (fix or feature that changes existing API behaviour)
• ♻️ Refactor (no functional change, no new feature)
• 🧪 Tests only (no production code changes)
• 📝 Documentation only
• 🔧 Chore (build, dependencies, CI config)

---

Pre-merge checklist (required)

Do not remove items. Unchecked items without an explanation will block merge.

Branch & metadata

• Branch name follows feature/issue-<N>-<slug> / fix/issue-<N>-<slug> convention
• Branch is up to date with the target branch (develop or main)
• All commits and the PR title follow the Conventional Commits format with issue reference

Code quality & tests

• npm run lint:ci — zero ESLint warnings
• npm run format:check — Prettier reports no changes needed
• npm run typecheck — zero TypeScript errors
• npm run test:ci — all tests pass, coverage ≥ 70%
• New service methods have corresponding .spec.ts unit tests
• New API endpoints are covered by at least one e2e test
• No existing tests were deleted (if any were, justification is provided in the PR description)

Error handling & NestJS best practices

• All new/updated DTOs use class-validator / class-transformer decorators and are wired through NestJS pipes (e.g. global ValidationPipe or explicit)
• All controller entry points validate external input at the boundary (no unvalidated raw any/unknown reaching the domain)
• Controllers/services throw appropriate NestJS HTTP exceptions (e.g. BadRequestException, UnauthorizedException, ForbiddenException, NotFoundException) instead of generic Error
• Any new error shapes are handled by existing exception filters or the filters have been updated accordingly
• Logging goes through the shared logging abstraction (e.g. Nest Logger or central logger service) with meaningful, structured messages
• Authentication/authorization guards (e.g. AuthGuard, role/permissions guards, custom guards) are applied to all new/modified endpoints where appropriate
• If an endpoint is intentionally public, this is explicitly mentioned in the PR description with rationale

API documentation / Swagger

• Swagger / OpenAPI decorators are added or updated for all new/changed controller endpoints (including DTOs, responses, and error schemas)
• I have started the app locally and confirmed the /api (or Swagger UI) reflects new/changed endpoints correctly
• If there are no API surface changes, this is explicitly stated in the PR description

Breaking changes

• This PR does not introduce a breaking API change
• OR: this PR introduces a breaking change and it is documented below, with migration notes

---

Breaking change description (if applicable)

---

Test evidence (required)

Commands run locally

# Example (edit as needed)
npm run lint:ci
npm run format:check
npm run typecheck
npm run test:ci

Manual / API verification

# Example: describe manual tests, curl commands, or Postman collections used

---

[drips-wave]

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

[RUKAYAT-CODER]

kindly resolve conflict and fix workflow.

[amankoli09]

@RUKAYAT-CODER I have fixed the changes. Please have a look to it if any changes to be made, just text me. Sorry for the inconvenience.

[RUKAYAT-CODER]

Thank you for contributing to the project.