Seed subscription and location from the environment and config defaults when we create an environment

We prompt for subscription and location even when we already know both. The prompt fires on "is this empty in the azd environment," and nothing fills the azd environment in except a prompt or an explicit `azd env new` flag, so a value the user already gave us somewhere else doesn't count.

Checked this against azd 1.31.2 and `azure.ai.agents` 1.0.0-beta.11:

- Exporting `AZURE_SUBSCRIPTION_ID` and `AZURE_LOCATION` does nothing. `azd ai agent init` with both set still says `Missing Azure environment values: AZURE_SUBSCRIPTION_ID, AZURE_LOCATION`, and neither one lands in `.env`.
- `azd config set defaults.subscription` / `defaults.location` don't seed either. They only pre-select an entry in the picker, so you still confirm two prompts to get to the values azd already picked for you.
- `AZURE_ENV_NAME` does work, but only by accident of implementation (it's bound as the default value of the `-e` flag in `internal/env_flag.go:31`). Subscription and location have no equivalent.

The workaround in our own pipeline docs is `azd env new --location --subscription `, which you can't run before a fresh init because there's no project yet:

```
$ azd env new hello-cs --location westus2 --subscription
ERROR: no project exists; to create a new project, run `azd init`
```

And if you stub an `azure.yaml` to get past that, template adoption refuses:

```
ERROR: a project azure.yaml already exists in ".", so the sample's unified azure.yaml cannot be adopted there
```

So on a greenfield init there's no way to hand us a subscription and a location without `--no-prompt`, and `--no-prompt` doesn't answer the questions. It skips the work and tells you to run `azd env set` before you provision.

I think the fix is to resolve both when we create the environment, in this order, and write the result into the environment so anything reading it later (including extensions through `AzureContext`) sees it:

1. Explicit flag (`--subscription`, `--location`)
2. Process environment (`AZURE_SUBSCRIPTION_ID`, `AZURE_LOCATION`)
3. `azd config` defaults
4. Prompt

That's what `AZURE_ENV_NAME` already does for the name, and it matches the comment we already have in `EnsureSubscriptionAndLocation` (`pkg/infra/provisioning/manager.go:380`) about persisting a system-environment value into `.env` so later commands don't re-read it. We just do that at provision time and not at environment-creation time, which is where the extension init flows need it.

We should say what we picked and where it came from rather than doing it silently:

```
Using subscription () from AZURE_SUBSCRIPTION_ID
Using location westus2 from azd config defaults.location
```

Explicitly not in scope here (all worth their own issues):

- `azd env new` needing a project to exist.
- Extension-supplied defaults. This is the slot a provider would write into, not the provider.
- Region validity. The agents extension rejects anything outside `hosted-agent-regions.json` and re-prompts, so a seeded location can still produce a prompt on that path. Which means this issue on its own doesn't get Foundry to zero prompts.

Start with the environment-creation flow and read internal/env_flag.go alongside EnsureSubscriptionAndLocation in pkg/infra/provisioning/manager.go. Trace how subscription and location are resolved and persisted into .env so extensions using AzureContext can read them. Done means flags, process environment, azd defaults, and prompts follow the stated precedence, with the selected values and their sources reported.

Written by the indexing model from the issue text.