Implement TTLSecondsAfterFinished and RunPolicy APIs

### What you would like to be added?

Implementation tracking for the APIs proposed in KEP-2899: https://github.com/kubeflow/trainer/pull/3824

What needs doing:

1. Add `ttlSecondsAfterFinished` to `TrainJobSpec` (`*int32`, mutable).
2. Add the `runPolicy` struct to `TrainingRuntimeSpec` with `activeDeadlineSeconds` and `ttlSecondsAfterFinished` as defaults that a TrainJob can override.
3. Add `startTime` and `completionTime` to `TrainJobStatus`, with the same semantics as JobSet: https://github.com/kubernetes-sigs/jobset/pull/1306
4. Add the CEL validations that reject `activeDeadlineSeconds` and `ttlSecondsAfterFinished` in the JobSet and Job templates, so cleanup is always owned by the TrainJob controller.
5. Implement value resolution and TTL enforcement in the controller. TTL deletes the TrainJob itself so the child JobSet, Pods, and Services cascade. This needs `delete` added to the TrainJob RBAC marker in `pkg/controller/trainjob_controller.go`.
6. Expose `ttl_seconds_after_finished` in the Kubeflow SDK.
7. Add unit, integration, and E2E tests per the KEP test plan, including a regression test for #3779.

cc @andreyvelich @robert-bell @tenzen-y @kuantian-zhang @kubeflow/kubeflow-trainer-team

### Why is this needed?

TrainJobs stay in the cluster indefinitely after they finish, and platform admins have no way to configure cleanup for all TrainJobs using a Runtime. As reported in #3779, stale Services and EndpointSlices from finished runs can resolve to reused Pod IPs and disrupt c10d rendezvous in new TrainJobs.

Setting `ttlSecondsAfterFinished` on the JobSet template does not solve this, since it deletes the JobSet while leaving the TrainJob behind, which the controller then recreates.

### Love this feature?

Give it a 👍 We prioritize the features with most 👍

Start with the TrainJob API types and pkg/controller/trainjob_controller.go, then compare the requested status semantics with JobSet and the KEP-2899 test plan. Trace Runtime and TrainJob value resolution, RBAC, cleanup, SDK exposure, and the existing regression area for #3779. Done means the APIs, CEL validation, controller behavior, SDK field, and unit, integration, and E2E coverage all match the requirements.

Written by the indexing model from the issue text.