Deprecate ambiguous AZURE_FUNCTIONS_AGENTS_MODEL fallback

> Please provide us with the following information:
> ---------------------------------------------------------------

### This issue is for a: (mark with an `x`)
```
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
```

### Minimal steps to reproduce
> 1. Configure Microsoft Foundry with `FOUNDRY_PROJECT_ENDPOINT`, but omit `FOUNDRY_MODEL`.
> 2. Set `AZURE_FUNCTIONS_AGENTS_MODEL` to a model-like value that is not the name of a deployment in that Foundry project.
> 3. Start an agent invocation.
> 4. The runtime selects Foundry and silently uses `AZURE_FUNCTIONS_AGENTS_MODEL` as the Foundry deployment name.

### Any log messages given by the failure
> `DeploymentNotFound: The API deployment for this resource does not exist.`

### Expected/desired behavior
> Deprecate and eventually remove `AZURE_FUNCTIONS_AGENTS_MODEL` as a provider-agnostic fallback. Model/deployment selection should use provider-specific settings so their semantics are unambiguous:
>
> - Microsoft Foundry: `FOUNDRY_MODEL` (Foundry deployment name)
> - Azure OpenAI: `AZURE_OPENAI_DEPLOYMENT` (Azure OpenAI deployment name)
> - OpenAI: introduce/document a dedicated provider-specific model setting, such as `OPENAI_MODEL`
>
> Keep `.agent.md`'s explicit `model` field as the highest-priority per-agent override. During a compatibility window, emit an actionable deprecation warning when the generic fallback is used. Update `client_manager.py`, tests, samples, and README/docs together.

### OS and Version?
> All supported platforms; reproduced on Windows.

### Versions
> Current `main` / experimental Dynamic Workflows sample as of 2026-08-17.

### Mention any other details that might be useful

> The generic setting currently crosses APIs with different naming semantics: OpenAI uses a model identifier, while Foundry and Azure OpenAI commonly require deployment names. This makes a valid-looking fallback fail only at request time and can select an unintended value when switching providers. This should be treated as a compatibility-sensitive configuration cleanup rather than simply renaming every setting to `FOUNDRY_MODEL`, because the runtime supports multiple providers.

> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Start with client_manager.py and the existing tests to trace how provider selection and AZURE_FUNCTIONS_AGENTS_MODEL fallback are handled. Check the .agent.md model override, then update samples and README/docs alongside the compatibility warning and provider-specific settings; run the affected tests to confirm the intended precedence and deprecation behavior.

Written by the indexing model from the issue text.