feat(transfer): support truthful destination storage classes

[cxymds]

Closes rustfs/backlog#1457

Background

cp --storage-class and pipe --storage-class were parsed but rejected unconditionally. The S3 transfer model can now carry destination storage class, while RustFS beta.10 has meaningful single-request behavior only for STANDARD and REDUCED_REDUNDANCY.

Root cause

The S3 adapter did not map storage class onto PutObject or CopyObject, command paths still used legacy methods, and multipart paths could not truthfully guarantee persistence. InvalidStorageClass also fell through to a generic network error.

Solution

• accept only STANDARD and REDUCED_REDUNDANCY as meaningful RustFS beta.10 policies
• send storage class on advanced PutObject and CopyObject requests
• wire cp single/planned upload and server-side copy paths plus pipe to advanced options
• reject label-only classes, unknown values, unknown sizes, and multipart transfers before mutation
• report selected class in human dry-run output without changing JSON contracts
• map service InvalidStorageClass to a stable UnsupportedFeature error
• preserve HEAD-observed storage class for copy results

Multipart persistence remains tracked by rustfs/backlog#1464; broader capability truthfulness remains tracked by rustfs/backlog#1465.

Validation

• cargo fmt --all --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• process-level mock S3 coverage for cp upload, remote copy, pipe, and dry-run
• independent review completed with no actionable findings