fix: S3 Control requests were served by S3, silently

[skyoo2003]

Summary

S3 Control requests were served by S3, and the write paths returned 200. s3control signs with S3's own signing name, so every call fell through DetectProtocol to the REST-XML default, where the S3 provider parsed PUT /v20180820/accesspoint/x as bucket v20180820, key accesspoint/x and stored it. That is a fabricated success against a registered service, which docs/coverage.md calls the one guarantee that must not bend.

Shipped alone because it is a correctness fix against released behaviour (#140) and depends on nothing else in Milestone 5.

Related Issue

Refs #

Changes

• DetectProtocol branch 4 splits s3-control off s3 by its /v20180820/ path prefix — the third instance of the URL-path split already used for opensearch and apigateway. Branch 4 was the only branch that never consulted SigningSiblings, even though aliases.SigningSiblings["s3"] already listed both.
• Regression tests at both levels, plus the boto3 file that proves the guarantee end to end.
• Changie Fixed fragment.

Why a path prefix, not the route table

A route-table split would be wrong here rather than merely larger: S3's own PutObject PUT /{Bucket}/{Key+} matches /v20180820/accesspoint/x, so asking which service models the path answers s3.

The one case this gets wrong, asserted rather than left to be found

A bucket named exactly v20180820 produces object paths under /v20180820/, which the prefix claims, so those objects become unreachable.

The alternative was measured and rejected. x-amz-account-id is bound by 96 of S3 Control's 97 operations and by 0 of S3's 107 — but gating on it routes the one operation that does not bind it, Outposts CreateBucket PUT /v20180820/bucket/{Bucket}, to S3, where it becomes a stored object and a 200. A wrong-but-honest error beats a fabricated success, so the shadowing stands and is tested.

Test Plan

RED, before the fix:

--- FAIL: TestDetectProtocol_S3Control/create_access_point
    expected: "s3control"
    actual  : "s3"

5 of 10 subtests failed; the 5 S3 guard subtests passed, so the failure was the defect, not the setup.

RED at the boto3 level, with the fix reverted (git revert --no-commit):

>       with pytest.raises(ClientError):
E       Failed: DID NOT RAISE ClientError

CreateAccessPoint returned a success and stored an object.

GREEN:

go test ./internal/gateway/ -run TestDetectProtocol_S3Control   11/11 subtests
CGO_ENABLED=0 go test ./...                                     111 packages ok
pytest tests/compatibility/                                     846 passed, 3 skipped

Manual, against ./dist/devcloud:

buckets unchanged: True | v20180820 absent: True

Checklist

• Self-reviewed the code
• Added/updated tests
• Lint/format passes (pre-commit: gofmt, go vet, go build, ruff)
• Updated documentation (if applicable) — N/A, the coverage docs move in the follow-up PR
• Added a Changie changelog fragment for user-facing changes