[Bug]: incorrect sibling logic when reading type from schema annotation

Description of the problem/issue

When defining @Schema(type = ...) on a model that is resolved to OAS 3.1, then the property is always marked as type: string. This is incorrect and it stems from a bug introduced in https://github.com/swagger-api/swagger-core/pull/4970. The issue is this change and more precisely that ctxSchema.type().getClass() will always produce the String class.

Affected Version

2.2.52

Earliest version the bug appears in (if known):
2.2.37

This was discovered in https://github.com/swagger-api/swagger-core/issues/5233 and thus reuses their steps to reproduce.

Steps to Reproduce

import io.swagger.v3.core.converter.AnnotatedType;
import io.swagger.v3.core.converter.ModelConverters;
import io.swagger.v3.core.converter.ResolvedSchema;
import io.swagger.v3.core.util.Json31;
import io.swagger.v3.oas.annotations.media.Schema;
import java.math.BigDecimal;

public class Repro {
  enum Freq { DAY, WEEK, MONTH }

  static class Dto {
    @Schema(title = "Inferred") public BigDecimal inferred;         // no explicit type (control)
    @Schema(title = "Amount", type = "number")  public BigDecimal amount;
    @Schema(title = "Count",  type = "integer") public Integer count;
    @Schema(title = "Flag",   type = "boolean") public Boolean flag;
    @Schema(title = "Unit")   public Freq unit;                     // enum (control)
  }

  public static void main(String[] args) {
    ModelConverters converters = new ModelConverters(true); // openapi31 = true
    ResolvedSchema resolved =
        converters.resolveAsResolvedSchema(new AnnotatedType(Dto.class));

    // root cause: scalar type is correct, but the "types" set is ["string"]
    resolved.schema.getProperties().forEach((name, s) ->
        System.out.println(name + " -> getType()=" + s.getType() + " getTypes()=" + s.getTypes()));

    System.out.println(Json31.pretty(resolved.schema));
  }
}

Expected Behavior

{
  "properties": {
    "inferred": { "type": "number" },
    "amount":   { "type": "number" },
    "count":    { "type": "integer" },
    "flag":     { "type": "boolean" },
    "unit":     { "type": "string", "enum": ["DAY", "WEEK", "MONTH"] }
  }
}

Actual Behavior

{
  "properties": {
    "inferred": { "type": "number" },                                  // OK (inferred, control)
    "amount":   { "type": "string" },                                  // WRONG, declared "number"
    "count":    { "type": "string" },                                  // WRONG, declared "integer"
    "flag":     { "type": "string" },                                  // WRONG, declared "boolean"
    "unit":     { "type": "string", "enum": ["DAY", "WEEK", "MONTH"] }  // OK (enum, control)
  }
}

Logs / Stack Traces

Additional Context

Checklist

• I have searched the existing issues and this is not a duplicate.
• I have provided sufficient information for maintainers to reproduce the issue.

Start with ModelConverters.resolveAsResolvedSchema using an AnnotatedType and openapi31 enabled, then inspect the sibling/type handling introduced by pull request 4970. Reproduce the output with the provided Repro example and add regression coverage for explicit number, integer, and boolean types while preserving inferred and enum properties. Done means the generated properties match the expected OpenAPI types.