fix: stamp endpoint on ai-project service in adopt flow for existing projects

[trangevi]

Why

When a user runs azd ai agent init, selects "Start new from a template", and chooses "Use an existing Foundry project", the subsequent azd up ignores that selection and provisions a brand-new account/project. The user's chosen project is never reused.

Root Cause

The "adopt" init flow (init_adopt.go) calls configureFoundryProject() which correctly sets environment variables (FOUNDRY_PROJECT_ENDPOINT, USE_EXISTING_AI_PROJECT=true, AZURE_AI_PROJECT_ID, etc.), but never writes the endpoint: field to the azure.ai.project service in azure.yaml.

The provisioning provider uses that endpoint: field as its brownfield signal -- if present, it connects to the existing project; if absent, it creates a new one. Since the adopt flow never stamped the endpoint, provisioning always took the "create new" path.

Fix

After configureFoundryProject returns with a non-nil FoundryProject, call SetServiceConfigValue to write the endpoint onto the existing ai-project service in azure.yaml. This uses the same existingProjectServiceKey helper the codebase already provides.

The resulting azure.yaml now includes:

ai-project:
    endpoint: https://<account>.services.ai.azure.com/api/projects/<project>
    host: azure.ai.project
    ...

Which the provisioning provider recognizes as brownfield, skipping new resource creation.

Testing

• Added TestAdoptFlow_WritesEndpointForExistingProject -- verifies the endpoint is written via SetServiceConfigValue when an existing project is selected
• Added TestAdoptFlow_SkipsEndpointWhenNoExistingProject -- verifies no endpoint is written when the user chose "Create new"
• All existing tests pass

Fixes: #9050

[github-actions]

📋 Prioritization Note

Thanks for the contribution! The linked issue isn't in the current milestone yet.
Thank you for logging this issue; our team is reviewing it. If you need urgent prioritization, tag @RickWinter and @kristenwomack to let us know.

[Copilot]

Pull request overview

This PR fixes issue #9050, where the azd AI agents "adopt" init flow (azd ai agent init → "Start new from a template" → "Use an existing Foundry project") ignored the user's existing-project selection and provisioned brand-new resources on the subsequent azd up. The provisioning provider treats the endpoint: field on the azure.ai.project service as its brownfield signal (synthesizer.go returns ErrEndpointBrownfield when set), but the adopt flow set the corresponding environment variables without ever stamping that endpoint: field into azure.yaml. The fix writes the endpoint onto the existing ai-project service via SetServiceConfigValue after configureFoundryProject returns a selected project.

Changes:

• After configureFoundryProject, stamp the selected project's Endpoint() onto the existing azure.ai.project service (Path: "endpoint") so provisioning recognizes the brownfield signal.
• Guard the write behind a non-empty endpoint and an existing project service key (existingProjectServiceKey), so the "create new" path is unaffected.
• Add two tests plus an in-process gRPC recording server/client helper.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
cli/azd/extensions/azure.ai.agents/internal/cmd/init_adopt.go	Stamps the existing project endpoint onto the ai-project service after project selection; correct brownfield mechanism and safe (result is non-nil on success).
cli/azd/extensions/azure.ai.agents/internal/cmd/init_adopt_test.go	Adds two "adopt flow" tests and a gRPC recorder helper; both tests bypass/duplicate production logic rather than exercising runInitFromAzureYaml, and the helper duplicates an existing same-package helper.