Archive Additional Command Args not applied to barman-cloud-check-wal-archive / barman-cloud-backup-list, breaking S3-compatible providers requiring virtual-hosted-style addressing

Environment:
- Barman Cloud plugin version: v0.14.0 (ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.14.0)
- barman-cloud Go module: v0.5.2-0.20260720143032-950b0f57e122
- Underlying barman-cloud-wal-archive binary version: 3.19.1
- CNPG operator version: 1.30.0 (ghcr.io/cloudnative-pg/cloudnative-pg:1.30.0)
- Object storage provider: Huawei Cloud OBS (S3-compatible, requires virtual-hosted-style addressing exclusively -- rejects path-style with 403 Forbidden on HeadBucket)

Summary:

spec.configuration.wal.archiveAdditionalCommandArgs on the ObjectStore CRD is documented as appending arguments to the barman-cloud-wal-archive invocation. In practice, it also needs to reach two other commands the plugin runs internally -- barman-cloud-check-wal-archive (the preflight check that gates the ContinuousArchiving cluster condition) and barman-cloud-backup-list (used by the retention/catalog-maintenance job) -- but it does not. This makes it impossible to configure --addressing-style virtual (or any other CLI flag) for providers that require it on all commands, not just the archive command itself.

Reproduction:

1. Configure an ObjectStore against an S3-compatible provider that requires virtual-hosted-style addressing (Huawei OBS in our case):

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
name: huawei-obs
spec:
configuration:
destinationPath: "s3://my-bucket/"
endpointURL: "https://obs.me-east-1.myhuaweicloud.com"
s3Credentials:
accessKeyId: {name: my-secret, key: ACCESS_KEY_ID}
secretAccessKey: {name: my-secret, key: SECRET_ACCESS_KEY}
region: {name: my-secret, key: REGION}
wal:
archiveAdditionalCommandArgs:
- "--addressing-style"
- "virtual"

2. Confirm the flag reaches the intended command -- logs show it correctly applied when barman-cloud-wal-archive itself runs.

3. Observe the cluster's ContinuousArchiving condition remains False/ContinuousArchivingFailing. Sidecar logs show the check command running WITHOUT the flag:

"options":["--endpoint-url","https://obs.me-east-1.myhuaweicloud.com","--cloud-provider","aws-s3","s3://my-bucket/","pg-16"]

(no --addressing-style present), followed by:

ERROR: Barman cloud WAL archive check exception: An error occurred (403) when calling the HeadBucket operation: Forbidden

4. Similarly, barman-cloud-backup-list (retention job) fails with:

ERROR: Barman cloud backup list exception: An error occurred (VirtualHostDomainRequired) when calling the ListObjectsV2 operation: Virtual host domain is required while accessing a specific bucket.

Confirmed working when tested manually, outside the plugin:

aws s3api head-bucket --bucket my-bucket --endpoint-url https://obs.me-east-1.myhuaweicloud.com --region me-east-1

fails with 403 Forbidden using default (path-style) addressing, but succeeds cleanly after:

aws configure set default.s3.addressing_style virtual

using the identical IAM credentials, bucket, and endpoint -- confirming the credentials, IAM policy, and bucket policy are all correct, and the only variable is addressing style.

Expected behavior:

archiveAdditionalCommandArgs (or a new, explicitly-documented mechanism) should apply consistently to every barman-cloud-* invocation the plugin makes against a given ObjectStore -- including the WAL archive preflight check and the retention/catalog commands -- not just the archive command itself.

Workaround attempted (did not work):

Setting BARMAN_S3_USE_PATH_STYLE=false via instanceSidecarConfiguration.env -- confirmed present in the running sidecar's environment via kubectl exec, but had no effect on the 403, suggesting this env var is not read by the underlying Go/barman-cloud-* invocation path at all.

Context:

This is affecting a data-residency-driven use case (Saudi Arabia in-Kingdom storage requirement), where Huawei OBS is one of the few providers with a live regional presence today. Happy to provide additional logs or test further configuration changes if helpful.

まず、archiveAdditionalCommandArgs がプラグインの barman-cloud-wal-archive 呼び出しにどのように渡されるかを追跡し、続いて内部の barman-cloud-check-wal-archive と barman-cloud-backup-list のエントリーポイントを確認します。引数が各コマンドに到達することを検証し、Huawei OBS のアドレス指定スタイルに関する失敗を再現します。すべての関連する呼び出しが、既存のアーカイブ動作を壊すことなく設定済みの引数を受け入れれば完了です。

索引モデルが issue の本文から書いたものです。