Fix ModelBuilder networking initialization with core Networking objects

[aryanputta]

Summary

• avoid assuming that core Networking objects expose a vpc_config attribute
• preserve the existing VPC config path when a legacy network object does provide vpc_config
• add regression coverage using the real sagemaker.core.training.configs.Networking type

Fixes #5827.

Testing

• python3 -m py_compile sagemaker-serve/src/sagemaker/serve/model_builder.py sagemaker-serve/tests/unit/test_model_builder_missing_coverage.py
• python3 -m compileall sagemaker-serve/src/sagemaker/serve/model_builder.py sagemaker-serve/tests/unit/test_model_builder_missing_coverage.py
• python3 - <<"PY"
  imported ModelBuilder with torch stubbed, instantiated a real Networking object, and verified that ModelBuilder initializes VpcConfig and network isolation without raising
  PY

Notes

• I attempted to run the sagemaker-serve unit tests directly, but local collection on this machine is blocked by optional heavyweight runtime imports from module scope, most notably torch.

[Mattral]

Hello there, one quick thing I want to learn from your PR, thanks for fixing the initialization logic to support both legacy and core Networking objects. One question: if future versions of Networking introduce new attributes beyond vpc_config, do you plan to handle those generically in ModelBuilder or continue patching case‑by‑case? Clarifying this could help maintainers plan for forward compatibility.

[aryanputta]

Hello there, one quick thing I want to learn from your PR, thanks for fixing the initialization logic to support both legacy and core Networking objects. One question: if future versions of Networking introduce new attributes beyond vpc_config, do you plan to handle those generically in ModelBuilder or continue patching case‑by‑case? Clarifying this could help maintainers plan for forward compatibility.

After looking through the code again, sagemaker.core.training.configs.Networking currently only exposes the fields that ModelBuilder actually uses here: subnets, security_group_ids, and enable_network_isolation. It does not seem to expose a stable vpc_config attribute, and ModelBuilder is already doing the normalization itself.

So I would lean toward keeping this fix narrow. ModelBuilder should support the two shapes it needs today: older objects that have vpc_config, and core networking objects that expose subnets, security_group_ids, and enable_network_isolation.

I would avoid copying over arbitrary future attributes unless those fields actually change the deployment request shape. If core Networking eventually adds one canonical method to convert itself into the request format, then I think that would be the cleaner long term path instead of adding open ended attribute introspection inside ModelBuilder.

Because of that, I do not think this PR needs another code change right now. The current fix is intentionally scoped: it normalizes the two known shapes without making ModelBuilder more tightly coupled to future Networking fields that it may not even need.
Happy to change anything you feel is needed.