fix(train): bound pydantic to <3.0.0 for cross-package consistency

[rsareddy0329]

Issue #, if available: Relates to #5652

Description of changes:

sagemaker-train declared pydantic>=2.0.0 with no upper bound, while
sagemaker-core declares pydantic>=2.0.0,<3.0.0. Installing sagemaker-train
on its own could therefore resolve a different pydantic major than the rest of
the SDK allows. This aligns the bound so all sub-packages agree on the pydantic
major, letting pip resolve a single consistent pydantic (and its matching,
pydantic-managed pydantic-core).

pydantic-core is intentionally not pinned: pydantic pins its own exact
pydantic-core, so pinning it here would fight that mechanism and cause more
conflicts, not fewer.

Scope note re #5652: the SystemError: The installed pydantic-core version ... is incompatible with the current pydantic version reported there comes from
upgrading pydantic-core independently of pydantic (e.g.
pip install ... pydantic-core --force-reinstall --no-deps), which no dependency
declaration can prevent. This change is the dependency-hygiene half of the fix —
it removes the version-skew gap between the sub-packages so a normal install lands
a consistent pair. Users who hit the mismatch after a manual pydantic-core
upgrade should realign with pip install --force-reinstall "pydantic>=2,<3".

Testing:

• sagemaker-train/pyproject.toml parses and the production pydantic constraint
  now matches sagemaker-core (pydantic>=2.0.0,<3.0.0). Metadata-only change; no
  runtime code affected.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Claude finished @rsareddy0329's task in 33s —— View job

---

PR Review: bound pydantic to <3.0.0

• Read the diff and gather context
• Verify constraint against other sub-packages
• Post review

---

Verdict: LGTM ✅

This is a clean, correct dependency-hygiene change.

Correctness

• The new constraint pydantic>=2.0.0,<3.0.0 in sagemaker-train/pyproject.toml:46 now exactly matches sagemaker-core/pyproject.toml:16, so all sub-packages that declare pydantic agree on the major. This removes the version-skew gap the PR describes.
• Not pinning pydantic-core is the right call — pydantic pins its own compatible pydantic-core, and pinning it separately would fight that mechanism. The PR body correctly scopes this as the dependency-hygiene half of [Bug]: PySDK V3: pydantic-core (2.42.0) incompatibility with sagemaker.ai_registry dataset import #5652 and notes that a manual pydantic-core --force-reinstall --no-deps can't be prevented by any declaration.
• sagemaker-train uses pydantic v2 APIs (v2-only features are used across the codebase), so an upper bound of <3.0.0 is safe and doesn't cut off any currently-supported version.

Notes (non-blocking)

• The test extra still lists a bare pydantic (sagemaker-train/pyproject.toml:60). That's harmless since the runtime dependency already constrains the resolve, and it's common practice, so no change needed.
• Observation, not a request for this PR: sagemaker-serve and sagemaker-mlops both import pydantic at runtime but don't declare it in their pyproject.toml dependencies (they rely on it arriving transitively via sagemaker-core). If the goal is full cross-package consistency, those two could eventually declare the same pydantic>=2.0.0,<3.0.0 bound explicitly. Out of scope here.

Tests: Metadata-only change with no runtime code affected; no new tests warranted.
· branch fix/pydantic-version-consistency