Default function regions are decided much later in prepare

[inlined]

This doesn't yet actually change the default from us-central1, but gives us a nice place to make all those changes.

us-central1 is GCP's oldest region and is oversubscribed. People use it because it's the default but it ends up having slower cold-starts and might even see more service disruptions. This is a place where we can examine new functions and decide whether there's a better place to put them. E.g.:

1. As a legacy feature, us-central1 functions are allow to listen to a backend from any region (e.g. an asia-east1 storage bucket with a us-central1 function). We can make the default match the event source and dramatically improve performance
2. For resources in the NAM5 multi-region, it may be better to use us-east1 for faster coldstarts
3. For functions on global resources, we might choose to look at the location defined in the user's admin config or just us-east1 again to move to a less subscribed region.

Nothing in here is intended to prevent a customer from deploying in us-central1 if they know they want to. This just helps us modify defaults for customers who have shown no preference.

[gemini-code-assist]

Code Review

This pull request implements deferred region resolution for Cloud Functions by introducing a REGION_TBD placeholder, which is later resolved by matching against existing functions or defaulting to us-central1. A review comment suggests reordering the preparation logic to call resolveDefaultRegions before inferDetailsFromExisting, ensuring that existing function metadata is correctly merged.

[Berlioz]

insaine -> insane

[Berlioz]

an -> and

[joehan]

Is this a user facing change? A bit hard to tell from the code without diving into the broader codebase

[inlined]

It will eventually but isn't yet.