feat(auth): gate repository responses on success field for all auth methods

[coderabbitai]

Summary

Currently, AuthRepositoryImpl methods (signIn, signUp, getCurrentUser, resendOtpCode) always return Result.success(...) when the API call completes without a HTTP-level error, without inspecting the success field on the response DTO.

If the backend returns HTTP 200 with success: false, the flow incorrectly advances as if the operation succeeded. Each method should gate on response.success and, when false, return Result.failure with an appropriate user-facing AuthFailure carrying response.message.

Note: This should be applied consistently across all auth repository methods once confirmed with the backend developer that the success field is reliably used.

Affected methods

• AuthRepositoryImpl.signUp — does not check RegisterResponseDto.success
• Potentially signIn and getCurrentUser depending on backend contract
• AuthRepositoryImpl.resendOtpCode — does not check ResendVerificationCodeResponseDto.success or message

Acceptance criteria

• All auth repository methods check response.success before returning Result.success(...)
• When response.success == false, return Result.failure with an AuthFailure carrying response.message as the user-facing message
• UnauthorizedAuthFailure continues to carry an empty message (silent redirect) per existing convention
• Unit tests cover the success: false path for affected methods

References

• PR: feat(auth): add sign-up flow and reusable auth form widgets #14
• Review comment: feat(auth): add sign-up flow and reusable auth form widgets #14 (comment)
• PR: feat(auth): implement resend verification code flow for email OTP #19
• Review comment: feat(auth): implement resend verification code flow for email OTP #19 (comment)
• Requested by: @CowboyGH

[CowboyGH]

Closing as not applicable.

Confirmed with backend: auth API does not use success: false as an application-level failure signal for otherwise successful 2xx responses. Client-visible failures are delivered via HTTP status codes and are already handled through DioException mapping in the repository layer.