feat(framework): define deterministic execution order for runtime plugins

### What you would like to be added?

**What would you like to be added?**

`Framework.New()` currently builds each plugin phase by iterating over the plugin registry map:

```go
for name, factory := range r {
...
f.enforceMLPlugins = append(...)
f.enforcePodSpecPlugins = append(...)
...
}
```

Since Go map iteration order is not stable, the execution order of plugins within the same phase is not explicitly deterministic.

Today this is mostly hidden because many plugins operate on distinct fields, but the framework increasingly relies on sequential PodSpec mutation and last-write-wins helpers such as `UpsertEnvVars`, `UpsertVolumes`, `UpsertVolumeMounts`, and `UpsertPort`.

The related discussion in #3887 already identified that cross-plugin conflicts may extend beyond env vars to ports, volumes, and volumeMounts. Without a deterministic ordering contract, future overlapping mutations could depend on registry map iteration rather than an intentional precedence rule.

### Why is this needed?

Runtime plugin execution should be reproducible and have an explicit precedence model.

A deterministic ordering mechanism would:

- make plugin behavior reproducible across controller starts;
- make conflict detection and warning semantics predictable;
- provide a stable contract for future runtime/infrastructure plugins;
- make tests able to assert plugin precedence intentionally rather than relying on map iteration.

Possible approaches could include sorting plugins by name as a minimal deterministic baseline, or introducing explicit phase priority/order metadata if semantic precedence is required.

I think the desired ordering contract should be agreed on before implementation, and I'd be happy to prototype the preferred approach.

**Relevant code**

`pkg/runtime/framework/core/framework.go`

Specifically `Framework.New()` and the phase slices:

- `enforceMLPlugins`
- `enforcePodGroupPolicyPlugins`
- `enforcePodSpecPlugins`
- `customValidationPlugins`
- `preComponentBuilderPlugins`
- `componentBuilderPlugins`

### Love this feature?

Give it a 👍 We prioritize the features with most 👍