`isWALArchiever` is ignored when multiple Barman Cloud plugins defined

## Summary

When defining **multiple entries with the same plugin name** (`barman-cloud.cloudnative-pg.io`) in `Cluster.spec.plugins`, WAL archiving appears to use the **parameters of the last matching entry**.

In practice, `isWALArchiver` can look ignored because WALs are pushed using `barmanObjectName` from the last plugin entry.

## Environment

- CloudNativePG: `1.29.1`
- plugin-barman-cloud: `0.12.0`
- Kubernetes: Kind (local)

## Minimal reproduction

Create two object stores:

- `store-a` (intended WAL target)
- `store-b` (intended backup-only target)

Then use a `Cluster` with duplicate plugin entries:

```yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: pg
spec:
instances: 1
imageName: ghcr.io/cloudnative-pg/postgresql:16
storage:
size: 1Gi
plugins:
- name: barman-cloud.cloudnative-pg.io
isWALArchiver: true
parameters:
barmanObjectName: store-a
- name: barman-cloud.cloudnative-pg.io
parameters:
barmanObjectName: store-b
```

Generate write traffic and inspect object stores.

## Expected behavior

WALs should go to `store-a` because that entry has `isWALArchiver: true`.

## Actual behavior

WALs are pushed to `store-b` (the last plugin entry in `spec.plugins`).

## Why this seems to happen

From source review:

1. CNPG validates "at most one WAL archiver" but does not reject duplicate plugin names.
2. CNPG selects WAL archiver by plugin **name**.
3. `plugin-barman-cloud` config extraction overwrites parameters on each matching plugin name while iterating, so the **last matching entry wins**.

## Relevant source references

- CNPG webhook validation (`at most one WAL archiver`):
- `internal/webhook/v1/cluster_webhook.go` (`validatePluginConfiguration`) [1]
- CNPG WAL archiver plugin name selection:
- `api/v1/cluster_funcs.go` (`GetEnabledWALArchivePluginName`) [2]
- plugin-barman-cloud parameter resolution (`last match wins`):
- `internal/cnpgi/operator/config/config.go` (`NewPlugin`, `NewFromCluster`) [3]

## Conclusion / Questions for maintainers

Could you please confirm whether this is the intended behavior when multiple
`spec.plugins` entries share the same plugin name?

If this behavior is intentional:

- Is it documented somewhere (especially the effective "last matching entry wins"
parameter resolution)?

If this behavior is not intentional:

- Are there plans to fix it (for example by rejecting duplicate plugin names in
validation or by making plugin resolution deterministic and explicit)?

Thanks for your time and for maintaining these projects.

[1] https://github.com/cloudnative-pg/cloudnative-pg/blob/758532a6f4bc148f7f73a769e3abbfe3ffbc710c/internal/webhook/v1/cluster_webhook.go#L2788
[2] https://github.com/cloudnative-pg/cloudnative-pg/blob/758532a6f4bc148f7f73a769e3abbfe3ffbc710c/api/v1/cluster_funcs.go#L1547
[3] https://github.com/cloudnative-pg/plugin-barman-cloud/blob/0bb78879ce8202addf1f0d3bbfbf4485f81a1290/internal/cnpgi/operator/config/config.go#L282

Bắt đầu với internal/cnpgi/operator/config/config.go, đặc biệt là NewPlugin và NewFromCluster, rồi tái hiện cấu hình có tên trùng lặp trong issue. So sánh cách xử lý đó với các tham chiếu về validation của CNPG và lựa chọn WAL-archiver. Được xem là hoàn tất khi hành vi đối với các entry trùng lặp được xử lý một cách rõ ràng và được một test phù hợp kiểm thử, hoặc được ghi tài liệu là có chủ đích.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.