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. A caller-provided
image_uri still takes precedence over the config's ImageUri (documented
on the method). The base/JumpStart branch of the setter continues to
require both config_name and instance_type — the instance_type-only
form is fine-tuned-only.

Instance-type matching honors the config's full offered set, not only
its default. A base config is a multi-instance bundle: list_deployment_
configs(instance_type=X) filters against each config's supported-instance
metadata (supported_inference_instance_types) and materializes the
matched configs FOR X, so a config that supports X but defaults to
another instance is neither discarded nor materialized at the wrong
instance. Recipe hosting configs are per-instance bundles by contract,
but SupportedInstanceTypes, when present, is honored for selection and
filtering so such a config is findable by any instance it offers; the
pinned instance is preserved through build. 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

Author: Lokiiiiii