fix(s3): honor the ACL headers on CopyObject, and share one resolver

[vieiralucas]

Summary

CopyObject read neither x-amz-acl nor the x-amz-grant-* headers and hardcoded the destination's ACL to the owner's FULL_CONTROL. So copy-object --acl public-read returned 200 and produced a private object — the caller believed it had published the copy. It was also the one object-write path that accepted an ACL for a bucket whose ObjectOwnership disables them, and the only one where --acl pubic-read (a typo) was silently ignored rather than refused.

The destination now takes its ACL from the request. A copy is a new object, so an unspecified ACL stays the default owner grant rather than inheriting whatever the source carried — that case has its own test, being the one most easily broken by "just copy the source's grants".

This was the first of the three gaps documented as out of scope in #2558.

One resolver instead of three copies

The three object-write paths each kept their own copy of the same four checks, and the order is load-bearing: the canned value is validated before the grant headers are resolved, and both before the "named two ways" rejection, so a request carrying an unresolvable grant answers InvalidArgument rather than InvalidRequest. The conformance probe populates the canned member and the grant members together, and only the first of those codes is in the S3 error allowlist — so a path that reordered its own copy would have silently dropped probe variants.

S3Service::resolve_write_acl_headers now holds that order once, and PutObject, CreateMultipartUpload and CopyObject all call it. Having one copy let two divergences be fixed in one place rather than three:

• AWS accepts an ACL granting nothing beyond the bucket owner against a BucketOwnerEnforced bucket — spelled x-amz-acl: bucket-owner-full-control or, in the AWS wording, "an equivalent form of this ACL", so an explicit full-control grant to the owner counts too. All three paths refused both.
• BlockPublicAcls was enforced only by PutObjectAcl/PutBucketAcl, so put-object --acl public-read stored an AllUsers grant on a bucket that blocks exactly that, while put-object-acl --acl public-read was refused. AWS refuses both.

One normalization worth flagging: CreateMultipartUpload checked ownership before validating the canned value, so an invalid value on a BucketOwnerEnforced bucket answered AccessControlListNotSupported. It now answers InvalidArgument, matching what PutObject already did — the value is wrong whatever the bucket allows. Both orders are pinned by tests.

Test plan

• Unit (486 passing): CopyObject honoring the canned header and the grant headers; a copy with no ACL headers staying private even when the source is public-read; CopyObject rejecting an invalid canned value, canned-plus-grants, and an ACL on a BucketOwnerEnforced destination; the owner-only exception accepted both as the canned value and as the equivalent explicit grant, with anything reaching past the owner still refused; BlockPublicAcls refusing a public ACL at write time while private passes; and the multipart error-code ordering pinned in both directions.
• Verified by reverting: with the destination ACL back to the hardcoded owner grant, both copy_object_honors_* tests fail.
• Suites: fakecloud-s3 486 passed; e2e s3, s3_anonymous_access, s3_copy_source_if_match, s3_persistence all green (127); fakecloud-conformance --test s3 51 passed; the s3 probe reports 4040/4068 variants, unchanged. cargo clippy --all-targets -- -D warnings and cargo fmt --check clean.

Surface sync

• Reference docs — website/content/docs/services/s3.md: the ACL bullet now covers CopyObject, and states the owner-only exception and that it applies to the object-write paths rather than to PutObjectAcl/PutBucketAcl.
• SDKs / introspection — no change: AWS API behavior, not a /_fakecloud/* surface.
• Counts / metadata — unchanged: no new operation, service or conformance variant, so conformance-baseline.json, the ops index, the README headline and the repo description all stay as they are.

---

Summary by cubic

CopyObject now honors the x-amz-acl and x-amz-grant-* headers instead of hardcoding the destination's ACL to the owner's FULL_CONTROL, so copy-object --acl public-read no longer returns 200 while producing a private object. A copy is a new object, so an unspecified ACL stays the default owner grant rather than inheriting the source's.

The three object-write paths (PutObject, CreateMultipartUpload, CopyObject) each kept their own copy of the same four ACL checks; they now share one resolver, resolve_write_acl_headers, which fixed three divergences. On BucketOwnerEnforced buckets the resolver accepts only the one ACL AWS names — the canned bucket-owner-full-control or the equivalent explicit grants giving the owner full control and nobody anything — rather than any ACL that resolves to owner-only grants; private, bucket-owner-read and aws-exec-read are still refused. BlockPublicAcls now refuses a public ACL at write time on all three paths rather than only through PutObjectAcl/PutBucketAcl. CreateMultipartUpload error order is normalized too: an invalid canned value on a BucketOwnerEnforced bucket reports InvalidArgument instead of AccessControlListNotSupported, and a present-but-blank x-amz-acl header is treated as absent, like the x-amz-grant-* family.

^{Written for commit cfb010f. Summary will update on new commits.}