fix(s3): judge the BucketOwnerEnforced exception against the bucket owner

[vieiralucas]

Summary

Follow-up to #2565, found by reviewing that PR's own follow-up commit after it had merged. Two defects, one user-visible.

The BucketOwnerEnforced exception judged the wrong owner

A BucketOwnerEnforced bucket accepts an object write that specifies no ACL, or one that specifies bucket owner full control -- "an equivalent form of this ACL expressed in the XML format" included, per CopyObjectRequest$ACL / PutObjectRequest$ACL in the vendored model. #2565 correctly narrowed the check to the ACL the request names, but compared the grantee against the caller rather than the bucket owner.

Those coincide for a bucket the caller created (create_bucket sets acl_owner_id = req.account_id), so the common path was right. They diverge for a bucket persisted by another account: the loader hydrates every persisted bucket into the configured default account (main.rs) while s3_bucket_from_snapshot keeps each bucket's own stored acl_owner_id. On such a bucket, under BucketOwnerEnforced:

• x-amz-grant-full-control: id=<caller> was accepted, storing an object ACL that gives the bucket owner nothing -- on a bucket whose entire purpose is that the owner owns and fully controls every object;
• x-amz-grant-full-control: id=<owner>, which AWS accepts, was refused.

The resolver now asks the bucket for its acl_owner_id, falling back to the caller when the bucket is not in memory -- that is the ordering where ACL headers are validated before the operation reports the missing bucket, and it preserves today's behavior there.

The test asserted the bug. It granted full control to 123456789012 while seed_bucket owns the bucket as "owner", so it passed only because of the wrong comparison: fixing the code would have failed it. It now asserts both directions against the real owner, and a grant to anyone else (the caller included) is AccessControlListNotSupported.

Reverting the blank x-amz-acl leniency

The same #2565 follow-up made a present-but-empty x-amz-acl count as absent on the object-write paths. That was wrong:

• "" is not a member of com.amazonaws.s3#ObjectCannedACL, and nothing in the model supports treating it as "no ACL asked for";
• main answered 400 InvalidArgument for it on PutObject and CreateMultipartUpload before fix(s3): honor the ACL headers on CopyObject, and share one resolver #2565 -- only CopyObject changed, because it had ignored ACL headers entirely;
• PutObjectAcl, PutBucketAcl and CreateBucket all still answer 400.

So the leniency made one operation disagree with four rather than fixing a regression. The x-amz-grant-* precedent cited for it is a different case: an empty value there names no grantee, whereas an empty x-amz-acl names an invalid ACL. Its test now pins the agreement across all the paths instead of the exception. (The copy of this leniency that had been added to #2566 was reverted there for the same reason.)

Also

• Drops a !g.is_empty() guard that could never be false -- resolved_grant_headers errors on an empty clause set rather than returning one -- and that read as though it were protecting the predicate.
• Docs: the "ACL ownership modes" bullet still said BucketOwnerEnforced "disables ACLs entirely (all ACL writes rejected)", which the exception falsified.

Surface sync

• Reference docs: website/content/docs/services/s3.md, the bullet above.
• SDKs / README / website copy / LLM-facing content / machine metadata: no change. No new or changed API surface, and no service, operation or variant count movement (probe re-run below), so the repo description needs no edit either.

Test plan

• cargo clippy --workspace --all-targets -- -D warnings -- clean
• cargo nextest run -p fakecloud-s3 -- 488 pass
• cargo nextest run -p fakecloud-e2e --test s3 --test s3_persistence --test s3_anonymous_access -- 126 pass
• cargo nextest run -p fakecloud-conformance --test s3 -- 51 pass
• conformance -- run --services s3 -- 4040/4068 variants, unchanged

Both fixes verified failing without them:

• restoring the account_id comparison fails bucket_owner_full_control_is_accepted_when_ownership_disables_acls
• restoring the blank filter fails a_blank_acl_header_is_rejected_on_every_acl_setting_path

---

Summary by cubic

Fixes the BucketOwnerEnforced object-write exception being judged against the caller instead of the bucket owner, and reverts an inconsistent leniency for blank x-amz-acl headers.

• On buckets persisted by another account, grants to the caller were accepted and grants to the actual owner refused; the check now resolves the bucket's stored acl_owner_id (looked up only when the request names an ACL), falling back to the caller when the bucket isn't in memory. The same owner id now also builds the resolved grants, which previously used the caller's.
• The test now pins both directions against the owner, and a grant to anyone else is AccessControlListNotSupported.
• Reverts treating a blank x-amz-acl as absent on the object-write paths, restoring the 400 InvalidArgument and keeping those paths consistent with PutObjectAcl, PutBucketAcl, and CreateBucket.
• Drops a dead !g.is_empty() guard and corrects the docs bullet that claimed BucketOwnerEnforced rejects all ACL writes and that reads return owner-only.

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