docs: add a migration guide for SageMaker and Vertex AI users

[apurvapatkeshwar]

Stacked on #1783. This guide lives in the migration section that PR creates (docs/user-guides/migration/_category_.json), so the branch is based on that PR's branch rather than main. The first commit here is #1783's, unchanged; only the last commit (docs: add a migration guide for SageMaker and Vertex AI users, one file, +112 lines) is new. Once #1783 merges I will rebase and the diff collapses to just this guide -- happy to hold review until then if that is easier.

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

What changed?

Adds docs/user-guides/migration/migrate-from-sagemaker-or-vertex.md, the third and final guide in the migration section asked for in #1705. It maps the managed-cloud concepts (Estimator/CustomJob, Pipelines, Model Registry, Endpoints) onto their equivalents here, shows a real Estimator-to-pipeline-task before/after with explicit model registration, and is deliberately blunt about what does not map today: batch inference, feature stores, hyperparameter tuning, native GCS storage, and endpoint traffic splitting.

Why?

#1705 asked for migration guides from Kubeflow Trainer, KubeRay, and SageMaker/Vertex. #1783 covers KubeRay and #1853 covers Kubeflow Trainer; this closes out the set. SageMaker and Vertex users are the audience most likely to be surprised by what a self-hosted platform does not bundle, so this guide leads with an honest gap list instead of letting people discover the gaps mid-migration.

How did you test it?

Docs-only change; testing here means accuracy and link integrity:

• Every capability claim was verified against the code and re-verified against current main before posting: the registry example uses the real APIRegistryClient signature (namespace= constructor kwarg; register_model(name=..., artifact_uri=..., kind=...)); the RayTask example uses the actual field names (head_cpu, head_memory, worker_cpu, worker_memory, worker_gpu, worker_instances); the blob storage layer at HEAD ships Azure and MinIO backends only, so the GCS gap is real (tracked in Native GCS backend for the blob storage layer #1693); the roadmap lists GCS, the feature store, and traffic splitting as planned, and mentions neither batch inference nor hyperparameter tuning, which the guide states plainly rather than implying they are scheduled.
• The guide intentionally does not enumerate serving backends: only Triton is registered in the Go backend registry today, and I did not want to repeat broader claims some existing docs carry.
• All relative links and heading anchors resolve against this branch's docs tree (the shared _category_.json resolves because of the stack).
• Filename, frontmatter, admonitions, and link style follow docs/contributing/documentation-guide.md.
• The docs build was not run locally (no bun on this machine) -- flagging so reviewers know to lean on the docs CI job.

Potential risks

None at runtime -- documentation only. The main risk is factual drift as gaps close (for example native GCS support in review at #1837); the gaps section points at the roadmap for anything planned, so it fails safe and stays easy to update.

Breaking Changes

• No breaking changes
• API changes (Go exported symbols or function signatures, Python public functions or classes)
• Proto changes (enum value renumbering, field number changes, field removal, service removal)
• Helm changes (new required values, renamed or removed keys, changed value semantics)
• Config/deployment changes (new required env vars, renamed container args, changed ports or mount paths)

Release notes

Docs only; nothing operational.

Documentation Changes

This PR is the documentation change: one new page under docs/user-guides/migration/.