One data point that may be useful, we run serverless SQL against several external locations that were created manually through the API rather than auto-created, and they read fine from serverless.

So I don't think you've hit a general rule that custom buckets can't work on serverless. What your debugging shows is narrower --- the registration event that should have added this one location to the serverless storage allowlist never converged, while the auto-created location registered during provisioning and did.

If that's the failure, the way out is to make the platform emit a fresh registration event.

There are two possible approaches I can think of:

- First (lowest lift): create a second external location on the same bucket at a different prefix and test it from serverless. If the new one works, the original's registration is stuck, and recreating the original should clear it. If the new one also fails, you have a clean reproduction that's worth escalating.
- Second: drop and recreate the original location. That's metadata only, your S3 data is untouched, but plan to recreate the external table definitions and grants that depend on it.