copy: support Object Lock retention and legal hold on copied files

[goanpeca]

Summary

Allow the copy verb to set Object Lock retention and legal-hold metadata on the destination object as part of the server-side copy request.

Why

Upload-time Object Lock is tracked in #107, but copied files have the same compliance need: the destination should be protected atomically when it is created. Without this, workflows must copy first and run the separate retention verb afterward, leaving a window where the copied object exists without the intended Object Lock policy.

SDK support (already available)

• RawClient.copyFile(...)
• CopyFileRequest.fileRetention
• CopyFileRequest.legalHold
• RetentionMode
• LegalHoldValue

Proposed surface

Extend copy with destination Object Lock inputs aligned with upload/retention naming:

• file-retention-mode (governance / compliance)
• file-retention-retain-until (RFC 3339 timestamp or epoch millis)
• legal-hold (on / off)

If the high-level SDK copy helper does not yet expose these fields, either use the raw SDK binding in the action or land a small SDK helper enhancement first.

Acceptance criteria

• copy can set retention on the destination object during the copy request.
• copy can set legal hold on the destination object during the copy request.
• Invalid Object Lock input combinations fail before making the B2 request.
• Existing copy behavior is unchanged when the inputs are omitted.
• Tests cover protected destination copies and ensure no secret values are logged.

Out of scope

• Bucket default retention, tracked in bucket defaults: default encryption and default retention #105.
• Upload-time retention, tracked in upload: support per-file Object Lock retention and legal-hold at upload time #107.