data.compression rejects zstd although barman-cloud-backup supports it

[dgsardina]

ObjectStore.spec.configuration.data.compression accepts bzip2|gzip|lz4|snappy, but not
zstd — even though the barman-cloud-backup binary in the sidecar image supports it.
wal.compression does accept zstd.

Versions: plugin v0.15.0 (chart 0.8.0), sidecar barman 3.20.0, CNPG 1.30.0.

barman-cloud-backup --help, from ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.15.0:

usage: barman-cloud-backup ... [-z | -j | --snappy | --lz4 | --zstd] [-h HOST]
  --zstd    zstd-compress the backup while uploading to the cloud

CRD on main:

data.compression.enum: [bzip2, gzip, lz4, snappy]
wal.compression.enum:  [bzip2, gzip, lz4, snappy, xz, zstd]

This looks like a lag rather than a decision: #200 added these algorithms on 2025-03-19,
when barman supported them for WAL only; EnterpriseDB/barman#1083 added --zstd to
base backups on 2026-07-04, and api/v1/objectstore_types.go has not changed
functionally since 2025-09-24.

Measured on 1.07 GiB of real pgdata/base (PG16 + TimescaleDB), single-threaded:

algorithm	ratio	compress	decompress
snappy	5.07x	583 MB/s	1138 MB/s
lz4	6.12x	521 MB/s	1583 MB/s
gzip	8.94x	78 MB/s	727 MB/s
bzip2	13.76x	8 MB/s	45 MB/s
zstd -3	11.46x	856 MB/s	1655 MB/s

zstd is faster than every permitted value in both directions, and only bzip2 compresses
better — at 1/100th the compression speed and 1/37th the decompression speed, the latter
being what a restore pays.

Request: add zstd to the data.compression enum and regenerate the CRD.

data.additionalCommandArgs: ["--zstd"] looks like a workaround, but I have not verified
the restore path end to end.