PodService.checkContainerFailures (4-arg) throws TaskException(-1, ...), dropping the real exit code and message

## 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. It is the **same bug class that PR fixed** (a real container exit code being reported as `-1`), still live in the shared path.

## Problem

`PodService.checkContainerFailures`' 4-arg, task-runner overload:

```java
public static void checkContainerFailures(Pod pod, String exceptContainer, Logger logger, AbstractLogConsumer defaultLogConsumer) throws TaskException {
Optional failed = findFailedContainer(pod, exceptContainer);
if (failed.isEmpty()) {
return;
}

logger.error(containerFailureMessage(failed.get()));
throw new TaskException(-1, defaultLogConsumer); // <-- drops exit code and message
}
```

`findFailedContainer` returns the `ContainerStatus` and therefore has the real terminated exit code and message in hand, but the throw discards both:

- **Exit code** is hardcoded `-1`, so `TaskException.getExitCode()` — and hence `ScriptOutput.exitCode` via `CommandsWrapper` — reports `-1` for a container that actually exited, say, `137` or `2`.
- **Message** is only logged, never attached. `TaskException(int, AbstractLogConsumer)` delegates to `"Command failed with exit code " + exitCode`, so the exception message becomes `Command failed with exit code -1` and the informative `containerFailureMessage(...)` text is lost to anything reading the exception (retry predicates, error handlers, the UI's exception message).

The 3-arg overload does the right thing by comparison — it throws `new IllegalStateException(errorMsg)` with the real message.

## Proposal

`io.kestra.core.models.tasks.runners.TaskException` already has a `(String message, int exitCode, AbstractLogConsumer logConsumer)` constructor, so:

```java
ContainerStateTerminated terminated = failed.get().getState().getTerminated();
String errorMsg = containerFailureMessage(failed.get());
logger.error(errorMsg);
throw new TaskException(errorMsg, terminated.getExitCode(), defaultLogConsumer);
```

Keep `-1` only as the fallback when no terminated state is available.

## Caller

`plugin-ee-kubernetes` `runner/Kubernetes.java:760` (the `hasFilesToDownload` branch) catches this `TaskException`, downloads output files, then re-throws it — so the wrong exit code and generic message propagate straight to the task result on that path.

## Files

- `src/main/java/io/kestra/plugin/kubernetes/shared/services/PodService.java` — `checkContainerFailures` 4-arg overload (~L315), `findFailedContainer` (~L325), `containerFailureMessage`

Start in src/main/java/io/kestra/plugin/kubernetes/shared/services/PodService.java at the 4-arg checkContainerFailures overload, then inspect findFailedContainer and containerFailureMessage. Check the caller at runner/Kubernetes.java:760 and verify that the task result preserves the terminated container's exit code and failure message, including the no-terminated-state fallback.

Written by the indexing model from the issue text.