Apply ValidateEnvReferences to the init and service env discovery paths

Follow-up from review on #9367.

## Context

`ValidateEnvReferences` (added in #9367, `internal/synthesis/envrefs.go`) refuses any `$` form outside `${VAR}`, `${VAR:-default}`, `$${VAR}` and `${{...}}`. It exists because drone/envsubst — which backs `foundry.ExpandEnv` — implements the full shell parameter grammar, so `${BAR:=x}`, `${BAR:+alt}`, `${BAR:?msg}`, `${BAR#p}` and `${BAR:0:3}` all expand even though `FindEnvReferences` reports none of them. It also refuses a reference nested in a `:-` default, which the expander resolves but the scanner deliberately does not report.

Where it runs, it makes the scan complete: every occurrence the expander acts on is one the scanner saw.

## Problem

It only runs on the three project network fields: `network.agentSubnet.vnet`, `network.peSubnet.vnet`, `network.dns.subscription`.

Every other Foundry field is scanned without it. `FindEnvReferences` is also the discovery source for:

- init prompting (`azure.ai.agents/internal/cmd/init_env.go`)
- the generated service env block (`azure.ai.agents/internal/cmd/resource_services.go`)

which cover agent `environmentVariables[*].value`, connection `target` / `credentials` / `metadata`, routine `action.input`, and toolbox `endpoint` / `tools`.

So `${BAR:=x}` in an agent `env:` value returns no references at all. init never prompts for `BAR`, the value gets no entry in the service env block, and `ExpandEnv` quietly rewrites it to `x` at deploy. Same one-character slip as the network case, different field, no diagnostic.

## Why it was not just switched on

Those paths are discovery, not validation:

- `collectAzureYamlEnvironmentReferences` and `collectStringEnvironmentTemplates` are collectors with no error return, so surfacing a refusal means threading an error out to the init/deploy callers and choosing where it is reported.
- The blast radius is every Foundry field in every extension, not three fields in one. An azure.yaml using envsubst grammar today *works* — it is just undiscovered — so refusing it turns a silent gap into a hard failure on manifests that currently deploy. That needs to be a deliberate, announced change, not a side effect of a `resolveVars` fix.

## Proposed work

1. Decide the policy: refuse, or warn and continue, for unsupported forms found during discovery.
2. Thread the result out of `collectAzureYamlEnvironmentReferences` / `collectStringEnvironmentTemplates` to the init and deploy call sites.
3. Report it with the service and field path, matching the network-field message.
4. Decide whether nested `:-` references are refused everywhere or stay tolerated outside the network fields, where they currently resolve at deploy for consumers that keep an azd environment fallback.

Related: #9427 (move the scanner into `pkg/foundry`).