refactor: Make LoginError type-safe using sealed class

[coderabbitai]

Summary

Currently, LoginError uses a flat data class with a nullable description field and a LoginErrorType enum. The LoginScreen force-unwraps description!! when handling LoginErrorType.BACKEND_SERVER errors, relying on a runtime contract rather than compiler-enforced type safety.

Proposed Refactor (Method 2)

Replace the current LoginError with a sealed class so that each error branch carries only the fields it needs — and BackendError.description can be non-null:

sealed class LoginError {
    data class BackendError(
        val description: String,  // non-null, compiler-guaranteed
        val code: String?
    ) : LoginError()

    data class OAuthError(
        val type: LoginErrorType,  // OAUTH_CLIENT, OAUTH_SERVER
        val code: String? = null
    ) : LoginError()
}

Then LoginScreen becomes:

when (val error = (loginUiState as LoginUiState.Error).error) {
    is LoginError.BackendError -> FeelinModalDialog(
        title = error.description,  // no !! needed
        description = "에러코드 [${error.code}]",
        ...
    )
    is LoginError.OAuthError -> FeelinModalDialog(
        title = "로그인 시도중 오류가 발생했어요.",
        description = "에러코드 [-1]",
        ...
    )
}

Motivation

• Eliminates the !! force-unwrap crash risk on LoginError.description.
• Compiler enforces that BackendError always has a non-null description.
• Removes the need for the LoginErrorType check inside the View layer.

Related

• PR: SCRUM-243 SCRUM-244 SCRUM-245 feature: kakao login and server login integration #14
• Review comment: SCRUM-243 SCRUM-244 SCRUM-245 feature: kakao login and server login integration #14 (comment)
• Requested by: @gdaegeun539