fix(backend): address issues #249, #250, #251, #252

[GF-Hunter]

Summary

This PR addresses backend issues #249, #250, #251, and #252.

Changes Included

1. Issue [backend] - GET /api/v1/admin/users/:phone exposes full phone number without masking #249: Mask phone number on GET /api/v1/admin/users/:phone

   • Replaced plaintext phone in the response with maskedPhone using the existing maskPhone helper function.
   • Added phoneHash (first 8 characters of SHA-256 hex digest) to support non-PII lookups and indexing.
   • Normalised the :phone route parameter before DB query via normalizePhone to prevent enumeration and format discrepancies.

2. Issue [backend] - No idempotency key support on POST /api/v1/trades — duplicate submissions create duplicate on-chain listings #250: Idempotency-Key support on POST /api/v1/trades

   • Supported optional Idempotency-Key header on trade creation.
   • Backed by cache with a 24-hour TTL for responses.
   • Duplicate submissions with the same idempotency key return the cached response without repeating the Soroban create_listing contract call or inserting duplicate records.
   • Added unit tests verifying duplicate requests return the cached response without repeating contract calls.

3. Issue [backend] - fraudDetection.checkVelocity uses in-memory cache which resets on restart, defeating rate-limiting across replicas #251: Shared Redis persistence and startup check for fraudDetection.checkVelocity

   • Updated validateEnv to require REDIS_URL in production.
   • Added startup verification of Redis readiness (cache.checkReady() with PING test); if Redis is unavailable at startup, the server logs FATAL and terminates with exit code 1.
   • Added fatal log level to custom structured logger.
   • Added integration test verifying that transaction velocity counts persist across client disconnection and reconnection (simulated process restart).

4. Issue [backend] - POST /api/v1/auth/recover/change-phone issues session JWT without verifying new phone ownership via OTP #252: Require OTP verification on POST /api/v1/auth/recover/change-phone

   • Updated phone recovery endpoint to invalidate the one-time recovery token immediately upon phone update.
   • Triggered OTP dispatch to the new phone number via Termii.
   • Returns a verification prompt without issuing a session JWT; the user must complete OTP verification via POST /api/v1/auth/verify-otp before receiving their session JWT.
   • Added unit test verifying OTP dispatch, lack of immediate session token, and recovery token invalidation against replay.

Closes #249
Closes #250
Closes #251
Closes #252

[drips-wave]

@GF-Hunter 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