fix: don't URL-encode V2 continuation tokens under encoding-type=url

[ServerSideHannes]

Problem

CNPG barman-cloud base backups and retention enforcement against buckets fronted by this proxy fail with:

ERROR: Barman cloud backup delete exception: Error during pagination:
The same next token was received twice:
{'ContinuationToken': 'production-v3/production/base/20260619T223000/data_0007.tar'}

This wedges Postgres base backups (stuck "starting up") and retention once a backup catalog grows past a single ListObjectsV2 page (~1000 keys). WAL archiving (PUT) is unaffected because it doesn't paginate.

Root cause

ListObjectsV2 continuation tokens are opaque cursors, not keys. Per the S3 spec, encoding-type=url only URL-encodes Key, Prefix, Delimiter, and StartAfter — not the continuation token — and botocore never URL-decodes it.

barman/botocore send encoding-type=url. The V2 serializer ran NextContinuationToken / ContinuationToken through _encode_key(..., encoding_type), so a key-shaped backend token like production-v3/production/base/.../data_0007.tar was emitted as …%2F…data_0007.tar. That token can't round-trip: the proxy decodes one layer, the backend doesn't recognize it, returns the same first page, and the identical token repeats → botocore's paginator aborts.

The handler already documented the correct behaviour (# V2 continuation tokens are opaque and must be passed back unchanged); only the serializer violated it.

Fix

Emit V2 NextContinuationToken / ContinuationToken XML-escaped only, regardless of encoding_type. Object keys remain URL-encoded under encoding-type=url.

Test

tests/unit/test_list_objects_continuation_token.py reproduces the loop: pre-fix the token comes back %2F-encoded (asserted failure), post-fix it's verbatim, and keys are still URL-encoded. Full unit suite green (539 passed).

Separate from #88 (Py2 except syntax + parallel list HEAD fan-out); this is the actual pagination-loop fix.