Sealed class nested subclasses with identical names cause schema collision

[Shun-Arahata]

Description

When two different sealed classes have nested subclasses with the same @SerialName, the OpenAPI schema generation produces conflicting definitions. The underlying schema-kenerator-serialization library incorrectly identifies these as the same type, causing schemas to be mixed together.

Minimal Reproduction

@Serializable
sealed interface ConfigA {
    @Serializable
    @SerialName("option1")
    data class Option1(val valueA: String) : ConfigA

    @Serializable
    @SerialName("option2")
    data class Option2(val valueA: String, val valueB: String) : ConfigA
}

@Serializable
sealed interface ConfigB {
    @Serializable
    @SerialName("option1")
    data class Option1(val fieldX: Int) : ConfigB  // Same name!

    @Serializable
    @SerialName("option2")
    data class Option2(val fieldX: Int, val fieldY: Int) : ConfigB  // Same name!
}

// Use both in API models
@Serializable
data class RequestA(val config: ConfigA)

@Serializable
data class ResponseB(val config: ConfigB)

When generating OpenAPI schemas for endpoints that use both RequestA and ResponseB, the component schemas for Option1 and Option2 collide.