PodService: share one terminated-container selection rule between failedMessage and the exit-code lookup

## Context

Follow-up from a review on [kestra-io/plugin-ee-kubernetes#191](https://github.com/kestra-io/plugin-ee-kubernetes/pull/191), explicitly scoped out of that PR because the code to change lives here.

That PR added a private `firstTerminatedExitCode(Pod)` helper in the EE task runner (`runner/Kubernetes.java`) so a pod that fails before ever being observed `Running` reports a real exit code instead of `-1`. Its rule is:

> first *failing* terminated container, else the first terminated container, else `-1`

This duplicates the container-selection logic already in `PodService.failedMessage(Pod)`, which builds the user-facing failure message from `getContainerStatuses().stream().filter(terminated != null).findFirst()` — i.e. **the first terminated container, regardless of exit code**.

## Problem

Two independent selection rules over the same `Pod` status means the exit code and the message can describe **different containers**. Concretely, for a pod where `main` terminated with exit 0 and a user sidecar terminated non-zero:

- `firstTerminatedExitCode` (EE, post-#191) picks the sidecar → correct non-zero exit code.
- `failedMessage` picks `main` → message reads `exitcode '0'` on a failed task.

Today `main` is first by construction in the EE runner, so the two happen to agree in the common case, but nothing enforces that and OSS callers have no such guarantee.

## Proposal

Move the helper into `PodService` next to `failedMessage` and have both share one selection rule:

```java
// PodService
static Optional firstFailingOrFirstTerminated(Pod pod);
```

- `failedMessage` builds its `exitcode '…'` / `message '…'` text from that container.
- A public `firstTerminatedExitCode(Pod)` (or equivalent) returns its exit code, `-1` when no container ever reached a terminated state (e.g. image-pull failure).
- `plugin-ee-kubernetes` drops its private copy and calls the lib.

This also makes the message less confusing on the sidecar case, since it stops reporting `exitcode '0'` for a failed pod.

## Files

- `src/main/java/io/kestra/plugin/kubernetes/shared/services/PodService.java` — `failedMessage` (~L263)
- consumer: `plugin-ee-kubernetes` `src/main/java/io/kestra/plugin/ee/kubernetes/runner/Kubernetes.java` — `firstTerminatedExitCode`

Start in src/main/java/io/kestra/plugin/kubernetes/shared/services/PodService.java at failedMessage around line 263, then inspect firstTerminatedExitCode in plugin-ee-kubernetes/src/main/java/io/kestra/plugin/ee/kubernetes/runner/Kubernetes.java. Trace how both select terminated containers and verify the shared helper covers failing, first terminated, and no-terminated-container cases. Done means both consumers use one selection rule and the private EE copy is removed.

Written by the indexing model from the issue text.