[BUG] REST calls for unimplemented operations are answered by another service sharing the path #6426

Service

Several REST services: AppSync, AppIntegrations, AppRegistry, MQ, Security Hub, Macie, Connect, Inspector, Lake Formation, Bedrock Agents

AWS API Action

Operations Floci doesn't implement for the signed service, whose path another service's controller also owns (full list below)

Expected behavior

Floci doesn't implement these operations, so I'd expect UnknownOperationException, the same as any other unimplemented operation.

Actual behavior

The request is answered by whichever service owns the same path, and writes go to that service's state. For example, AppRegistry's CreateApplication creates an AppConfig application, and AppSync's CreateApi creates an API Gateway v2 API.

I found these with a sweep that called every operation of every REST service in botocore (10,369 calls, placeholder values for required members). These are the 31 calls that reached another service's route:

None of these are operations Floci claims to support, so the impact is limited to clients calling something unimplemented and getting another service's response (or side effect) back instead of an error.

Reproduction

aws --endpoint-url http://localhost:4566 servicecatalog-appregistry create-application --name from-appregistry
aws --endpoint-url http://localhost:4566 appconfig list-applications
# 💥 lists a new AppConfig application: {"Items": [{"Id": "adbe849"}]}
#    (no name, since AppRegistry sends `name` and AppConfig reads `Name`)

Environment

• Floci version / image tag: floci/floci:nightly (repro), sweep run against main at 99171dcbe
• How you're running Floci: Docker

Notes

I tried fixing this in #6368 by refusing a REST request that reaches a controller owned by a service it isn't signed as. That turned out to be the wrong shape: CloudFront viewer requests signed for an S3 origin need to reach CloudFront's serving route, the IAM route-enforcement tests deliberately check a request against the route it reached whatever its scope, and several test suites sign every call with one scope. So I've backed it out.

I'm not sure what the right fix is, if any is worth it. Maybe a 404 for the specific conflicting operations, rather than a general rule? Raising it here so it's recorded, and I'd love to hear what you think.