Remove-Hardcoded-User-IDs-and-Magic-Values

[shamoo53]

CLoses #205
What does this PR do?

This PR introduces transaction management across critical multi-step operations to ensure atomicity and data consistency. It wraps sensitive workflows such as authentication token generation and payment + invoice creation within database transactions, preventing partial writes during failures. Additionally, retry logic for deadlocks and transaction-level logging have been implemented to improve reliability and observability.

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-- / fix/issue-- 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
All controller entry points validate external input at the boundary
Controllers/services throw appropriate NestJS HTTP exceptions
Any new error shapes are handled by existing exception filters
Logging goes through the shared logging abstraction with structured messages
Authentication/authorization guards are applied where appropriate
If an endpoint is intentionally public, this is explicitly mentioned in the PR description

API documentation / Swagger

Swagger / OpenAPI decorators are updated where necessary
Verified Swagger UI reflects changes correctly
No new public API endpoints were introduced (internal service-level improvement)

Breaking changes

This PR does not introduce a breaking API change
Test evidence (required)

Commands run locally

npm run lint:ci ✅
npm run format:check ✅
npm run typecheck ✅
npm run test:ci ✅

Manual / API verification

• Simulated partial failure in auth flow → transaction rolled back successfully
• Simulated failure in payment + invoice creation → no partial data persisted
• Verified retry logic triggers on simulated deadlock scenarios
• Checked logs to confirm transaction lifecycle (start, commit, rollback)