feat(transfer): add secure SSE-C source and destination keys

[cxymds]

Closes rustfs/backlog#1459.

Background

SSE-C transfers require a 256-bit customer key on every relevant S3 request. Accepting that key literally on the command line or allowing it into diagnostics would expose sensitive material, while sending it over an untrusted transport would disclose the derived header value on the wire.

Root cause

The transfer adapter modeled SSE-C keys but the CLI had no secure file/environment input path, and the RustFS S3 adapter still rejected SSE-C writes and reads. Multipart, planner metadata reads, checksum verification, and pinned compatibility tests also lacked SSE-C propagation.

Solution

• add file- and named-environment key inputs for cp and pipe; require exactly 32 bytes, zeroizing storage, protected regular files, and redacted formatting/errors
• add trusted-HTTPS enforcement before any SSE-C request; expose alias set --ca-bundle for verified private endpoints
• derive AES256, base64 key, and base64 MD5 headers internally for PutObject, CreateMultipartUpload, every UploadPart, HeadObject, and GetObject
• propagate source and destination keys through direct and planned upload/download paths, destination existence checks, and checksum verification
• fail closed before requests for beta.10 server-side SSE-C copies, which remain tracked by rustfs/backlog#1467
• add child-process leakage/exit-code tests and a TLS-pinned beta.10 CLI integration covering file/env input, single upload, source download, wrong key, multipart upload, and explicit re-encryption rejection
• update both smoke and scheduled integration jobs plus the capability probe to trust the ephemeral test CA

Validation

• cargo fmt --all --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• bash -n scripts/probe-rustfs-compatibility.sh
• workflow YAML parse check

The local Docker daemon was unavailable, so the pinned RustFS beta.10 TLS integration is delegated to the PR CI gate.

[cxymds]

Final validation summary:

• All required PR checks passed on Linux, macOS, and Windows.
• RustFS beta.9 and beta.10 smoke jobs passed; beta.10 exercised SSE-C over a dedicated trusted TLS endpoint.
• The manual full-target run passed 67 tests and failed only the three existing SSE-S3 cases where RustFS beta.10 returns HTTP 500 InternalError.
• A control run from current main reproduced the exact same three SSE-S3 failures (66 passed), confirming they are an existing server baseline rather than a regression in this PR.
• Final review-thread audit found no comments, reviews, or unresolved threads.