Thanks — checked all three:

1. Workspaces tab on the external location shows "All workspaces have access", so it's not in isolated mode — it should be auto-allowlisted.

2. Can't use the explicit allowlist workaround — we're on the Premium tier, so managing storage destinations on the network policy isn't available to us.

3. Re-ran the system.access.outbound_network query — still empty, no DROP rows for this bucket yet. Will check again later in case the logs are lagging.

So the full state is: binding is all-workspaces, bucket and metastore are both us-west-2, IAM/trust/credential all validate (UC vends session credentials, Browse works, classic compute works), the only network policy is allow-all, and the auto-created external location works from the same serverless session while this manual one gets "denied because of serverless network policy".

One detail I should have mentioned earlier: both this workspace and the external location were created today. Could this simply be propagation? i.e., does the serverless egress allowlist for a brand-new workspace + newly created external location take up to 24 hours to converge — and would that also explain why the auto-created external location works (registered during workspace provisioning) while the manual one doesn't yet?

If that's expected behavior, I'll retest in fresh serverless sessions over the next day and report back. If it still fails after 24 hours, I'll open a support ticket with the workspace ID and trace ID.