refactor(manifests): use named container ports for better maintainability

[ChughShilpa]

The current manifests use hardcoded port numbers in probes and service definitions. This makes it harder to maintain and understand the configuration at a glance.

Proposed changes:
Add explicit containerPort declarations with named ports and update probes and service to use named ports.

This makes the manifests more self-documenting and easier to maintain

[github-actions]

🎉 Welcome to the Kubeflow Trainer! 🎉

Thanks for opening your first issue! We're happy to have you as part of our community 🚀

Here's what happens next:

• Our team will review your issue soon! cc @kubeflow/kubeflow-trainer-team
• If you'd like to contribute to this issue, check out our Contributing Guide for repo-specific guidelines and the Kubeflow Contributor Guide for general community standards.

Join the community:

• Slack: Join our #kubeflow-trainer Slack channel.
• Meetings: Attend the Kubeflow AutoML and Training Working Group bi-weekly meetings.

Feel free to ask questions in the comments if you need any help or clarification!
Thanks again for contributing to Kubeflow! 🙏

[andreyvelich]

Thanks for creating this @ChughShilpa, do we really need to have those ports defined in the Deployment manifests?
We haven't done it before, and users didn't complain. I feel like users can always check service if they want to verify port number.

[robert-bell]

Naming ports isn't strictly necessary, but it can be quite nice when a container exposes a number of ports - you use a name in readiness/liveness probes and the service. It might be handy with #2905 if we end up adding another port for the trainer status messages.