Add Stellar address validation, mainnet payment kill-switch, build SHA in health check, and consolidated auth error messages

[CeceOs92]

Title

Add Stellar address validation, mainnet payment kill-switch, build SHA in health check, and consolidated auth error messages

Summary

• Validate Stellar addresses in DTOs — added a checksum-based @IsStellarPublicKey() validator (backed by StrKeyHelper/stellar-sdk, not just a shape regex) and wired it into every DTO that accepts a Stellar address: BuildTransactionDto, FeeBumpTransactionDto, CreateTransactionDto, ReconcileBalanceDto, BalanceFilterDto. BuildTransactionDto previously had no validation decorators at all.
• Mainnet payment submit feature flag — FeeBumpService.submitFeeBump now checks a mainnet_payment_submit flag (FEATURE_MAINNET_PAYMENT_SUBMIT) before submitting any network: "MAINNET" fee-bump transaction to Horizon, returning a 403 if disabled. TESTNET submissions are unaffected.
• Build git SHA in health endpoint — GET /health now returns build: { gitSha }, sourced from a GIT_SHA env var (wired into the Dockerfile as a build arg), merged into both the healthy response and the 503 failure body for a consistent shape.
• Consolidated external auth error messages — POST /auth/authenticate no longer leaks raw downstream error text (e.g. "DB unavailable", "Stellar unavailable") into the HTTP response. Unclassified failures now throw a single ServiceUnavailableException with a generic, consolidated message; the real cause is still logged server-side only.

Details

#515 — Validate Stellar addresses in DTOs

• New reusable decorator: src/common/stellar/is-stellar-public-key.validator.ts (+ spec)
• Applied to build-transaction.dto.ts, fee-bump-transaction.dto.ts, create-transaction.dto.ts, reconcile-balance.dto.ts, balance-filter.dto.ts
• Replaced a shape-only regex (^G[A-Z0-9]{55}$) with real StrKey checksum validation, catching typos/bit-flips a regex would miss

#522 — Add feature flag for mainnet payment submit

• FeeBumpService now injects FeatureFlagService; gates MAINNET submissions before any wallet key decryption or Horizon call
• Swagger docs updated with the new 403 response
• docs/MAINNET-PAYMENT-FEATURE-FLAG.md added
• Tests: flag disabled → 403 (Horizon never called), flag enabled → succeeds, TESTNET never consults the flag

#548 — Expose build git sha in health endpoint

• HealthController reads GIT_SHA via ConfigService (default "unknown"), merges build.gitSha into success and 503 failure responses
• Dockerfile — ARG GIT_SHA=unknown / ENV GIT_SHA=$GIT_SHA, injectable via --build-arg GIT_SHA=$(git rev-parse HEAD)
• .env.example documents the new var
• New health.controller.spec.ts covering success, missing-env default, DB-down 503 (with gitSha still present), and non-Terminus errors passing through unchanged

#550 — Consolidate external auth error messages

• auth-orchestrator.service.ts: replaced throw new Error(\Authentication failed: ${error.message}`)(a plainError, only sanitized in NODE_ENV=production) with throw new ServiceUnavailableException(EXTERNAL_AUTH_FAILURE_MESSAGE)— a single consolidated, generic message, consistent with the filter'sHttpException` handling used everywhere else
• Real error cause is still logged via the existing logger.error(...) call — never dropped, just never echoed to the caller
• Updated auth-orchestrator.integration.spec.ts and auth-metrics.integration.spec.ts, which previously asserted on the leaked raw error text as expected behavior, to instead assert the generic message and that the raw cause is absent

Test plan

• npm ci && npm test — not run in this environment (no node_modules present in the sandbox); please run before merging
• Reviewed diffs for each change manually
• Manual smoke test of POST /transactions/build, POST /transactions/fee-bump (MAINNET on/off), GET /health, POST /auth/authenticate failure path

Closes #515
Closes #522
Closes #548
Closes #550

[drips-wave]

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