add_kubernetes_metadata processor should include container data when matching /var/log/pods/

**Describe the enhancement:**

When using the `logs_path` matcher with `resource_type: "pod"` (e.g., reading from `/var/log/pods/`), the matcher extracts a pod UID and looks it up against the `pod_uid` indexer. However, the `PodUIDIndexer` only generates pod-level metadata and does **not** include container-specific metadata (`container.name`, `container.image`, `container.id`, `container.runtime`).

This means that when collecting logs from `/var/log/pods/` paths, events are enriched with Kubernetes pod metadata but **lack container-level information** — even though the container name is available in the log path itself:

```
/var/log/pods/__//0.log
```

By contrast, when using `resource_type: "container"` with `/var/log/containers/` paths, the matcher extracts the container ID and uses the `container` indexer, which correctly includes all container metadata (`container.name`, `container.image`, `container.id`, `container.runtime`).

**Describe a specific use case for the enhancement or feature:**

When Filebeat is configured to use a single filestream input to all k8s logs, reading logs from `/var/log/pods/` (the standard Kubernetes log directory), it needs the `add_kubernetes_metadata` processor for k8s metadata. A typical configuration looks like:

```yaml
processors:
- add_kubernetes_metadata:
matchers:
- logs_path:
logs_path: "/var/log/pods/"
resource_type: "pod"
indexers:
- pod_uid:
```

In this scenario, events get pod-level Kubernetes metadata (pod name, namespace, labels, etc.) but are missing:
- `kubernetes.container.name`
- `kubernetes.container.image`
- `kubernetes.container.id`
- `kubernetes.container.runtime`
- The corresponding ECS `container.*` fields

The container name is readily available in the log file path but the matcher currently ignores it when `resource_type: "pod"`.

**What's feasible and what's tricky:**

The `/var/log/pods/` path format contains both the container name and the restart counter in its structure:

```
/var/log/pods/__//.log
```

- **`container.name`**: Directly extractable from the path. This is straightforward and should definitely be supported.

- **`container.image`**: Can be resolved by matching the extracted container name against the pod spec's container list (`pod.Spec.Containers[].Image`).

- **`container.id` and `container.runtime`**: These are trickier. A container gets a new ID every time it restarts, but the container name stays the same. During a CrashLoopBackOff, a pod can even have two containers with the same name — the one that was just killed and the newly started one. The `.log` file in the path distinguishes between these restarts (e.g., `0.log` for the first run, `1.log` after the first restart, etc.). It's unclear whether this level of resolution is practical or worth the complexity.

**Possible approach:**

At a minimum, the matcher should extract the container name from the path and include `container.name` (and potentially `container.image` from the pod spec) in the metadata.

Resolving `container.id` from the restart counter is an open question This could be a follow-up enhancement or left as a known limitation.