Smart Placement not smart enough - let's have Dumb Placement!

For Workers & Pages, what is the name of the domain?

foo

What is the error number?

foo

What is the error message?

foo

What is the issue or error you’re encountering

foo

What steps have you taken to resolve the issue?

I’m using a Worker to help me migrate some data into R2. It’s almost what slurpy does, but not quite so I’ve written my own small Worker to do it.
This basically works well, but it’s slow. I’m in Scotland, and I’m transferring data to an R2 bucket in the US from a source also in the US. With default placement, these gigabytes of data are crossing the Atlantic twice.
“Smart Placement” doesn’t help, because it only considers placements where the worker has already run. I’m the only person invoking this worker so it always runs at my local edge location; Smart Placement never discovers that it would be much faster to run near the R2 bucket.
This could be fixed with a “Dumb Placement” system, i.e. if I could specify “prefer to run this Worker near the R2 bucket that it is bound to”.
Question: is there any “hack” that I can do to achieve the same thing?
I am considering starting an EC2 instance in a location that I guess is closer to the R2 bucket, but that’s a bit too much work.

What are the steps to reproduce the issue?

Why is this forum post form formatted as a bug report? Is this “community” actually a bug reporter?

Use a location hint when creating the bucket…

Use a location hint when creating the bucket…

No, the location hint when creating the bucket only determines where the bucket is located. It doesn’t determine where the worker that I’m using to upload content into the bucket is located.