fix: restrict Agent init adoption to agent services

[huimiu]

Why this is needed

azd ai agent init -m <pointer> is meant to initialize an Agent. Before this change, it treated several Foundry-related service hosts as a signal that the input was an Agent project, even when the manifest only contained sibling services such as a project or connection. Those projects could sometimes be adopted and deployed, but the Agents extension had no Agent to configure. This made the command's behavior unclear and made service ownership harder to maintain.

What changes

The command now adopts a unified azure.yaml only when it contains a service with host: azure.ai.agent.

• Real Agent samples continue to use the same adoption flow.
• Agent manifests continue to use the existing generation flow.
• Project-only or sibling-service-only manifests are no longer silently adopted as Agent projects; the Agent init command is now reserved for Agent inputs.
• The unsupported microsoft.foundry service host is no longer treated as an Agent service. Its use as infra.provider: microsoft.foundry is unchanged.
• Help text and environment-reference handling are updated to match the supported behavior.

This approach keeps the Agents extension focused on the service it owns instead of maintaining a growing list of other Foundry service hosts. It also avoids adding a separate early-validation rule that could block existing project-only workflows outside the Agent init command.

Closes #8888

E2E validation

• Unified Agent manifest adoption: PASS — azure.ai.agent manifests were adopted and copied to the project root.
• Standard Agent manifest initialization: PASS — the existing generation flow completed successfully.
• Sibling-host fallback: PASS — manifests containing azure.ai.project did not trigger Agent adoption and initialized through the normal Agent flow.
• Legacy-host fallback: PASS — microsoft.foundry was not treated as an Agent service and initialized through the normal Agent flow.
• Help text: PASS — the command documents that adoption requires host: azure.ai.agent.

[Copilot]

Pull request overview

Restricts Agent initialization adoption to unified manifests containing an azure.ai.agent service.

Changes:

• Narrows adoption detection to Agent services.
• Removes legacy microsoft.foundry host handling.
• Updates help text and regression tests.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
internal/cmd/init.go	Clarifies adoption requirements.
internal/cmd/init_env.go	Removes legacy host environment handling.
internal/cmd/init_env_test.go	Tests ignoring legacy host references.
internal/cmd/init_adopt.go	Restricts adoption detection to Agent hosts.
internal/cmd/init_adopt_test.go	Covers sibling and unsupported hosts.

[jongio]

Two things worth tightening here.

MEDIUM

• init.go:1059 - a unified azure.yaml with no agent service now fails with an AgentManifest error that points at the wrong schema, after a project folder has already been created.

LOW

• init_adopt.go:37 - the function name and doc comment no longer describe what the function does.

The $ref case flagged at init_adopt.go:64 is real, but narrower than it reads. I left the details on that thread.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[jongio]

I verified the new ref handling locally. A service that is only $ref: ./services/agent.yaml, with the host living in the referenced file, resolves to true. A service with an inline host: azure.ai.project next to a $ref at an agent file resolves to false, because sibling keys overlay the loaded file. That precedence is subtle and nothing pins it down.

Still open from my last pass: init.go:1059. A unified azure.yaml with services: and no agent service still creates the project folder first and then fails with must contain 'template' field, which sends the author to the AgentSchema docs for a field they shouldn't add. That thread hasn't been answered and this commit doesn't change the behavior.

LOW

• init_adopt.go:74 - ResolveFileRefs errors are dropped, so a missing, misspelled, URL, or cyclic $ref silently reports "no agent service" and lands on that same wrong error path.
• init_adopt_test.go:135 - the new ref branch has one happy-path test. The documented remote skip, a ref that resolves to a non-agent host, and the sibling overlay precedence are all uncovered.

[trangevi]

Approving pending Jon's comments

[jongio]

Two things beyond what I already flagged.

LOW

• init_env.go:281 - dropping microsoft.foundry from environment-reference handling reaches past "restrict Agent init adoption to agent services", and the extension still ships a schema and a provisioning-host entry for that host. Details inline.
• This changes what azd ai agent init -m accepts, but there's no CHANGELOG entry. Recent behavior fixes in this extension carried their own entry (#9291, #9212, #9211), so is this one waiting on the release-prep PR instead?

My earlier notes on init.go:1059, the swallowed ResolveFileRefs error, and the untested $ref branches are still open.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (2)

cli/azd/extensions/azure.ai.agents/internal/cmd/init.go:1060

• The --manifest flag help remains broader than this new restriction: init.go:1563 still says any unified azure.yaml can be adopted, and the generated Fig completion text repeats that at cli/azd/cmd/testdata/TestFigSpec.ts:904. Update both to state that adoption requires an azure.ai.agent service; cli/azd/AGENTS.md:241 requires all related help text and snapshots to stay aligned with command behavior. (azd-code-reviewer)

declares a service with host: azure.ai.agent), that azure.yaml is adopted as
the project manifest and its referenced files are placed at the project root.

cli/azd/extensions/azure.ai.agents/internal/cmd/init.go:1340

• This return means sibling-only and microsoft.foundry project manifests do not “initialize through the normal Agent flow” as the PR’s E2E section claims; they stop here with invalid_manifest_pointer. Align the implementation or update those E2E results so the documented customer behavior matches what ships. (azd-code-reviewer)

						return missingAgentServiceError(flags.manifestPointer)