WAL restore: support reading WAL files from a Barman Cloud object-store layout as a fallback (read-only)

## Problem

When a requested WAL segment isn't found in Klio's native archive, there's currently no way to check whether it exists in a Barman Cloud archive in the same object store, and no way to retrieve it if so. This blocks replay of WAL that predates a cluster's migration to Klio.

## Requirements

- Read-only: no write against Barman Cloud objects.
- No dependency on the barman-cloud plugin being installed or running.
- Must support Barman Cloud's WAL directory layout and all its supported compression variants (none, gzip, bzip2, snappy), inferred from the file name.
- No key/path collision with Klio's own WAL layout in the same bucket: this must be confirmed as impossible, not assumed.
- Behaviour must be configuration-gated: fully inert when disabled, no extra object-store calls, no change to existing behaviour.

## Verification

- [ ] WAL restore falls back to the Barman Cloud layout when a segment is absent from Klio's native archive, feature enabled.
- [ ] All three compression variants decompress correctly.
- [ ] With the feature disabled, behaviour and object-store call volume are identical to today.
- [ ] No key/path collision between Klio's layout and Barman Cloud's layout in the same bucket, confirmed by test.
- [ ] No write operation is ever issued against Barman Cloud objects, confirmed by test.
- [ ] Covered by unit tests against both layouts, and an integration/e2e test using a bucket seeded with Barman Cloud-formatted WAL.

## Open questions

- Confirm whether Barman Cloud's WAL hash-dir sharding scheme matches Klio's own, or whether the two must be computed independently.

## Out of scope

- Recovering a base backup in Barman Cloud format (sibling ticket).
- Retention/cleanup of legacy Barman Cloud objects (future ticket).