[azure.ai.routines] Declarative deploy can target a different project than azure.ai.agents

- [x] Make sure you've installed the latest version using [instructions](https://github.com/Azure/azure-dev?tab=readme-ov-file#installupgrade-azure-developer-cli)

**Output from `azd version`**

```text
azd version 1.31.2
azure.ai.agents 1.0.0-beta.11 (latest installed)
azure.ai.routines 1.0.0-beta.4 (latest installed)
```

**Describe the bug**

An `azure.ai.agent` service and an `azure.ai.routine` service in the same `azure.yaml` can resolve different Foundry projects when the active azd environment contains both project endpoint variables and their values differ:

```text
FOUNDRY_PROJECT_ENDPOINT=https://.services.ai.azure.com/api/projects/
AZURE_AI_PROJECT_ENDPOINT=https://.services.ai.azure.com/api/projects/
```

The agents extension resolves the active environment's `FOUNDRY_PROJECT_ENDPOINT`, while the routines extension prefers the active environment's `AZURE_AI_PROJECT_ENDPOINT`. As a result, `azd deploy ` PUTs the Routine to the stale project even though its `uses:` dependency and target agent are deployed in the current project.

The service then returns a misleading target-validation/AgentIdentity error because the named endpoint does not exist in the project selected by the routines extension. The agent and its `instance_identity` do exist in the project selected by the agents extension.

**To Reproduce**

1. Use an active azd environment where `FOUNDRY_PROJECT_ENDPOINT` points to project A and a stale `AZURE_AI_PROJECT_ENDPOINT` points to project B.
2. Define an agent and dependent Routine in `azure.yaml`:

```yaml
services:
chief-of-staff:
host: azure.ai.agent
# hosted agent configuration omitted

weekday-chief-of-staff:
host: azure.ai.routine
uses:
- chief-of-staff
enabled: false
triggers:
default:
type: schedule
cron_expression: "0 8 * * 1-5"
time_zone: America/New_York
action:
type: invoke_agent_invocations_api
agent_name: chief-of-staff
input:
notification: Good morning
```

3. Confirm that `azd ai agent show chief-of-staff --output json` finds an active agent with an `instance_identity` in project A.
4. Run:

```powershell
azd deploy weekday-chief-of-staff
```

The deployment sends its PUT to project B and fails:

```text
RESPONSE 400: 400 Bad Request
ERROR CODE: UserError
Cannot validate routine target agent invoke access because the routine target agent endpoint 'chief-of-staff' could not be resolved for AgentIdentity authorization.
```

Explicit `azd ai routine show ... --project-endpoint ` queries the stale project, while `--project-endpoint ` queries the project containing the agent. This confirms that the failure is project selection, not missing AgentIdentity RBAC.

**Expected behavior**

Declarative Routine deployment should resolve the same project as its dependent `azure.ai.agent` service. The routines extension should prefer the active azd environment's canonical `FOUNDRY_PROJECT_ENDPOINT`, with `AZURE_AI_PROJECT_ENDPOINT` only as a compatibility fallback.

If both variables are set and differ, azd should fail before the PUT with an actionable project-context conflict instead of sending the request to the wrong project and surfacing a misleading AgentIdentity error.

**Environment**

- Windows / PowerShell
- azd 1.31.2
- azure.ai.agents 1.0.0-beta.11
- azure.ai.routines 1.0.0-beta.4

**Additional context**

The resolver difference is visible in:

- `cli/azd/extensions/azure.ai.agents/internal/cmd/agent_context.go`: active azd env -> `FOUNDRY_PROJECT_ENDPOINT`
- `cli/azd/extensions/azure.ai.routines/internal/cmd/endpoint.go`: active azd env -> `AZURE_AI_PROJECT_ENDPOINT`

#8688 fixed the same endpoint-variable split for the toolbox workflow, but the routines service target still has the conflicting precedence.

Current workaround:

```powershell
$values = azd env get-values --output json | ConvertFrom-Json
azd env set AZURE_AI_PROJECT_ENDPOINT $values.FOUNDRY_PROJECT_ENDPOINT
azd deploy weekday-chief-of-staff
```