feat(serve): support fine-tuned models in deployment-config API

Make ModelBuilder.list_deployment_configs / get_deployment_config /
set_deployment_config work for fine-tuned (model-customization) models
in addition to base/JumpStart models, dispatching internally on
_is_model_customization(). For fine-tuned models the recipe's published
HostingConfigs are the source of truth; selection is by instance type
(recipe configs are largely unnamed).

The base "deployment config" vs recipe "hosting config" distinction is
internal and does not surface: fine-tuned configs are normalized to the
same shape the base response returns (DeploymentConfigName plus a nested
DeploymentArgs block with the base DeploymentArgs keys, present as None
when a recipe does not provide them — a compatible superset), so a
caller can iterate results from either pathway identically.
BenchmarkMetrics/AccelerationConfigs are None; an additive IsDefault
flag marks the recipe's Default config.

set_deployment_config(instance_type=...) applies the whole matching
config (image, environment, compute requirements) at build time and
raises on an unpublished or ambiguous instance type. list_deployment_
configs(instance_type=...) filters to configs offering that instance.
Configs published with only DefaultInstanceType are matched
consistently end to end so they are not silently dropped at build.

Config discovery (recipe-level with a top-level HostingConfigs fallback)
is centralized in _extract_hosting_configs_from_hub() and used by BOTH
the selection API and the build path, so a top-level config that is
listable/selectable is also applied at build. Nova models are routed to
their dedicated build path first (per-tier SMI validation + Nova env
precedence), so the top-level fallback never diverts them. An explicit
selection stores a deep copy of the raw config, is applied exactly at
build (or raises if its instance type is no longer published), and the
endpoint instance type is re-synced to the selected bundle. Returned
configs are copied so caller mutation cannot corrupt internal state.

This is the SDK half of a paired change; the SageMaker agent
model-deployment skill consumes this unified API. Internal CR:
https://code.amazon.com/reviews/CR-289903643

Testing: python3 -m pytest
sagemaker-serve/tests/unit/test_recipe_hosting_config_selection.py (48
tests) covering shape parity (tied to the base DeploymentArgs slots),
top-level-fallback build application, Nova-first routing + SMI
validation, explicit-selection exact-apply / stale-raise / instance
re-sync, repeated selection, mutation isolation (incl. cross-path to
build), compute-requirements propagation, base get/set paths, and the
recipe-level/top-level/unmatched discovery matrix. Base-model regression
suites pass under valid credentials (they exercise live JumpStart/STS).

Author: Lokiiiiii