Add an InitProvider capability so extensions can answer init's questions instead of the user

[tg-msft]

azd init asks for an environment name, a subscription, and a region. For most people none of those are real decisions. They're just things we need before we can do anything, so we make the user supply them. An extension almost always knows a better answer than the user does, and today it has no way to tell us.

Foundry is the clearest example of the shape (not the point of this issue, just the case that makes it obvious). The agents extension has quota-aware region logic already - PromptAiModelLocationWithQuota, and an automatic "select a model deployment based on availability and quota" path in no-prompt mode. But it only gets to run that after azd has already asked the user to pick a region. So we ask a question the user can't answer well, they guess, and then the extension goes and works out the real answer anyway.

The workaround shape is the tell. The only way to influence init's defaults today is to replace init. azd ai agent init scaffolds the project itself and then shells out to azd init -t <dir> <target> --environment <name> through the Workflow API. Any extension that wants a say in init has to reimplement init. We declare eight extension capabilities right now (custom-commands, lifecycle-events, mcp-server, service-target-provider, framework-service-provider, provisioning-provider, validation-provider, metadata) and none of them cover this.

I think we want a new interface like InitProvider where azd asks the provider before it asks the user:

• azd hands the provider what it knows so far (working directory, selected template, subscription if we have one, the manifest as it stands).
• The provider returns values and a reason for each. Environment name, location, and subscription to start with, designed so we can add more later.
• azd applies them and says what it did, including who supplied it. Something like Using westus2 (microsoft.foundry: only region with gpt-5.4-mini quota in this subscription). If we're going to answer questions on someone's behalf they need to be able to see the answer and where it came from. We can leave breadcrumbs for users to change anything we defaulted.
• Anything a provider answered, we don't prompt for.

Precedence I'd start with is explicit user input, then process environment, then provider, then our own config defaults, then prompt. Worth arguing about whether a provider should beat azd config defaults.location. I lean yes, because we can give that value to the provider which it can then consider against its other options.

Two things the interface needs beyond "here's a value":

• A provider has to be able to say "I don't know," and we fall straight through to today's behavior. Returning nothing should be completely normal.
• A provider has to be able to say "the value you already have won't work, and here's why." Right now when the agents extension gets a region it doesn't support it warns, throws the value away, and drops into a picker. If someone deliberately picked a region, quietly replacing their choice with a prompt is worse than failing with a message that says what was wrong with it.