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 ImageUri/InstanceType/Environment/
ComputeResourceRequirements and the other base DeploymentArgs keys,
present as None when a recipe does not provide them), so a caller can
iterate results from either pathway identically. BenchmarkMetrics and
AccelerationConfigs are None (recipes publish none today); an additive
IsDefault flag marks the recipe's Default config (a compatible superset,
not a byte-identical shape).

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 (_fetch_and_cache_recipe_config),
so a top-level config that is listable/selectable is also applied at
build. An explicit set_deployment_config() selection stores a deep copy
of the raw config and is applied exactly at build (or raises if its
instance type is no longer published) rather than silently falling back;
a constructor-supplied instance type keeps the prior warn-and-fallback
behavior. Returned configs are copied so caller mutation cannot corrupt
internal selection 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 (41
tests) covering shape parity (tied to the base DeploymentArgs /
DeploymentConfigMetadata slots), top-level-fallback build application,
exact/again-resolvable explicit selection vs stale-selection raise,
repeated selection, mutation isolation, user-image-uri precedence, and
the recipe-level/top-level/unmatched discovery matrix. The base-model
regression suites pass under valid credentials (they exercise live
JumpStart/STS paths).

Author: Lokiiiiii