Nice debugging, that error string settles it: the denial is coming from the serverless egress layer, not AWS, and the auto-created vs manual split is the tell. Serverless auto-allows a bucket only when the external location is bound to the workspace or open to all workspaces, and binding changes can take up to 24 hours to take effect.

1. Open Catalog Explorer, go to the manual external location, Workspaces tab. If it's in isolated mode and this workspace isn't listed, bind it (or set it to all workspaces).

2. To unblock right away, add the bucket explicitly under Allowed Storage Destinations on the network policy in the Account Console. That's the documented way to expedite and propagates in about 10 minutes. While you're there, confirm which policy this workspace is actually attached to; the "allow all" one you checked may not be it.

3. If the binding looks right and it still fails after the propagation window, open a support ticket with the workspace ID and trace ID you offered. Support can check whether the bucket is registered on the egress side for your workspace, and the explicit allowlist entry keeps you running in the meantime.

Also worth re-running the system.access.outbound_network query later; system tables can lag, and the DROP rows with the rejection reason are the strongest evidence to attach to a ticket.