Handle INITIALIZING account status in TokenVerificationProvider

[phertyameen]

Summary

Issue #85 introduces a new INITIALIZING account status to represent the window between a database record being created and the Soroban contract being successfully initialized. TokenVerificationProvider.validateAccountStatus() uses a switch statement to handle every known account status. Once INITIALIZING exists as a valid status, any account in that state will hit the default case and throw 'Invalid account status': a confusing and technically incorrect error for an account that is simply still being set up. This issue adds explicit, meaningful handling for the new status.

Background: The account creation window

When a user calls POST /accounts, the account record is saved to the database immediately with INITIALIZING status before the Stellar account is created and the contract is initialized. This window exists so there is always a traceable database record even if the on-chain steps fail. In normal operation this window is very short, a few seconds at most. But in degraded conditions (slow Soroban RPC, network issues), an account could remain in INITIALIZING for longer.
If a recipient somehow receives a claim URL during this window, for example, if the claim URL was sent via email before account initialization confirmed, and tries to verify it, they should receive a clear message explaining the account is being set up, not a generic invalid status error.

Understanding validateAccountStatus

The method is a defensive gate in the claim flow. It runs before any claim attempt and throws specific exceptions for each status to give the caller enough information to respond correctly. Each status maps to a different HTTP exception type for a reason, ConflictException for already claimed, UnauthorizedException for expired, BadRequestException for not ready. The new INITIALIZING case should follow this same pattern with an appropriate exception type and a message that makes sense to an API consumer.

What the correct behavior should be

An account in INITIALIZING state is not yet ready to be claimed but it is not in an error state. The correct response is a BadRequestException with a message that communicates the account is still being set up and the caller should try again shortly. Do not throw UnauthorizedException, the token is not invalid, the account is just not ready yet.

Where to look

• src/modules/claims/providers/token-verification.provider.ts: the validateAccountStatus() method that needs updating
• src/modules/accounts/entities/account.entity.ts: the AccountStatus enum where INITIALIZING was added by Issue Make account creation atomic - handle failure between Horizon and contract initialization #85
• The other case branches in validateAccountStatus: use them as a reference for the pattern this project follows for status-specific error handling

Acceptance Criteria

• validateAccountStatus() has an explicit case for AccountStatus.INITIALIZING
• The INITIALIZING case throws BadRequestException with a message indicating the account is still being set up
• The default case remains as a genuine catch-all for truly unexpected statuses
• Unit tests cover the INITIALIZING case alongside the existing status cases
• This change is implemented after Issue 85 lands do not merge before INITIALIZING exists in the enum