Generalize custom type detection in nested Pydantic models

[AdilFayyaz]

Tracking issue

Duplicated from: flyteorg/flyte-sdk#664

Why are the changes needed?

Ensure flytekit is up to date with flytesdk

What changes were proposed in this pull request?

• When guess_python_type reconstructs a Python type from a Flyte LiteralType
  (JSON schema), nested custom types with registered TypeTransformers were being
  rebuilt as generic dataclasses instead of being recognized as their original
  types. This is because the schema reconstruction code never consulted
  TypeEngine._REGISTRY for registered types when resolving $ref entries or inline
  nested objects.
• Added schema_match() method to TypeTransformer that auto-matches for
  BaseModel subclasses by comparing JSON schema fingerprints (title, type,
  required fields). No user override needed — registering a transformer for a
  BaseModel subclass is sufficient.
• Added _match_registered_type_from_schema() helper that iterates all
  registered transformers to find a match.
• Replaced the fallback-to-generic-dataclass paths in
  generate_attribute_list_from_dataclass_json_mixin,
  _handle_json_schema_property, and _get_element_type with the generalized
  helper, so any registered custom type is recognized before a synthetic
  dataclass is created.

How was this patch tested?

pytest tests/flytekit/unit/core/test_custom_type_in_nested_pydantic.py — 7 new
tests covering _match_registered_type_from_schema (match, no match),
guess_python_type structure verification (direct, List, Dict, nested List), and
default schema_match behavior. Note: File/Dir schema match tests and the
mixed-type model test from v2 are not included because FlyteFile/FlyteDirectory
are not BaseModel subclasses in v1 and therefore do not benefit from the
auto-match logic.

Setup process

Screenshots

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Docs link