feat: server-side passthrough for same-credential encrypted COPY

[ServerSideHannes]

Problem

Scylla Manager backs up each SSTable, then copies it to its snapshot-tagged key (X -> X.sm_<tag>, same bucket, CopyObject with MetadataDirective=COPY). Normally a copy is a free server-side metadata op. But because this proxy does client-side AES-256-GCM, _copy_encrypted implements every encrypted copy as GET source -> decrypt -> re-encrypt -> PUT dest — turning a "rename" into a full download + re-upload of the whole object.

Measured live: the fleet was pushing ~750 MB/s up and ~730 MB/s down to Hetzner simultaneously (bytes_encrypted ~= bytes_decrypted), with ~1000 COPY_OBJECT/3 min. Real new-data goodput was tiny (~24 MB/s); the rest was copy amplification. It saturated the CPU/AES-bound proxy and produced a PutObject 503 SlowDown storm (940 rejections/3 min on scylla), stalling the daily backup at ~16%.

Fix

The ciphertext isn't key-bound — GCM AAD is None, the DEK is random and stored in object metadata (isec) / the multipart sidecar, and nonces are embedded in the ciphertext. So a byte-identical copy that keeps the same wrapped-DEK metadata decrypts fine under any key name.

handle_copy_object now issues a native server-side CopyObject when all hold:

• metadata_directive == "COPY",
• same credential — source kid == caller (so re-keying is a no-op),
• ciphertext <= 5 GiB (single-op CopyObject limit).

Multipart objects also get their .meta frame-map sidecar server-side-copied. Unchanged fallbacks: cross-credential copies still re-encrypt (re-key under the caller's KEK), and so do REPLACE and >5 GiB objects.

Verification

• Real Hetzner: CopyObject COPY on a 1.68 GB encrypted SSTable preserves isec / isec-kid user metadata byte-for-byte (same size). Temp copy deleted after.
• Tests (tests/integration/test_copy_passthrough.py): single-object + multipart passthrough (asserts no source download / no dest re-upload, round-trips to original plaintext) and the REPLACE re-encrypt fallback. Full unit suite (457) + per-key/streaming-copy/copy-governing suites green; ruff clean.

Impact

Same-credential dedup copies (Scylla's case) drop from "whole file down + re-encrypt + whole file up" to a metadata-only server-side op — removing the ~750 MB/s-each-way amplification and the 503 storm, so the backup can finish and finalize its manifest.

Follow-up (out of scope)

5 GiB objects still fall back to re-encrypt; upgrade path is server-side UploadPartCopy per 5 GiB range (noted with a ponytail: comment).