fix: range-aware passthrough for Scylla manifest UploadPartCopy

[ServerSideHannes]

Summary

• Root cause of 2026.7.14 still streaming: Scylla sends bytes=0-(~4768MB-1) on .sm_* manifests while source big-Data.db sidecar total_plaintext_size is ~6GB. PR fix: passthrough Scylla manifest UploadPartCopy with full-object range #121 only cleared ranges matching metadata total, so _can_passthrough_part_copy still rejected any range → UPLOAD_PART_COPY_STREAMING → 300s timeout → HAProxy 400.
• Fix: Large ranged copies from offset 0 that align to internal ciphertext segments now use range-aware passthrough (server-side upload_part_copy per segment, no re-encrypt).
• Observability: New UPLOAD_PART_COPY_ROUTE log with route, raw_copy_source_range, metadata_total_plaintext_mb, range_plaintext_mb, and passthrough_blocked_reason.

Tests

• test_scylla_prod_shape_range_smaller_than_metadata_uses_passthrough — 149 internal parts, metadata inflated 1.27× (prod shape), range smaller than metadata total → passthrough not streaming
• test_prod_shape_passthrough_eligibility_and_route — eligibility + normalize does not strip Scylla range
• test_segments_for_plaintext_range_* — segment alignment helper
• test_small_partial_range_blocked_from_passthrough — partial 32MB range still re-encrypts
• All existing passthrough + copy pipeline unit tests pass (24)

Post-deploy verification

kubectl logs -n s3proxy-python -l app.kubernetes.io/name=s3proxy-python --since=30m \
  | rg 'UPLOAD_PART_COPY_ROUTE|UPLOAD_PART_COPY_PASSTHROUGH'

Expect route=passthrough and UPLOAD_PART_COPY_PASSTHROUGH on *.sm_* manifest keys; UPLOAD_PART_COPY_STREAMING count should drop sharply.

Made with Cursor