[ext-foundry]: make project/connection/toolbox Foundry resources real service targets

[huimiu]

Implements the per-resource service-target design of unified azure.yaml spec #8590 (docs/specs/unify-azure-yaml/spec.md) §2.2, §2.6, §2.8, plus §1.4 (endpoint:).

#8675 writes each Foundry resource as its own azure.yaml service (azure.ai.project / azure.ai.connection / azure.ai.toolbox) but registers all three as no-op service targets inside azure.ai.agents; the resources are still provisioned by Bicep at provision time and re-sourced through the pre/postprovision + postdeploy hooks in listen.go. This issue moves each host to its owning sibling extension with a real deploy-time upsert.

Summary

Turn azure.ai.project, azure.ai.connection, and azure.ai.toolbox into real service targets owned by their sibling extensions, so azd deploy reconciles each resource (upsert) in uses: order, with native per-service progress and failure attribution.

Scope

Per host — each a vertical slice that: registers the host + service target, publishes <kind>.json, adds the core-schema conditional, removes the host from the agents no-op ResourceServiceTargetProvider, and moves its reconcile out of the listen.go hooks into the resource's Deploy:

• azure.ai.project -> azure.ai.projects: resolve the project (provisioned, or via endpoint: §1.4) and upsert each deployment.
• azure.ai.connection -> azure.ai.connections: upsert the connection; resolve env secrets.
• azure.ai.toolbox -> azure.ai.toolboxes: upsert the toolbox; resolve named connection references.

Note: azure.ai.skill and azure.ai.routine real service targets are covered in #8779.

Ordering stays in azure.yaml via uses: (project -> connections -> toolboxes -> agents); azd core topologically orders them.

Out of scope (follow-ups)

• Agent-host shape + legacy migration -> [ext-agents]: evolve azure.ai.agent to service-level shape, retire agent.yaml, add migration #8773.
• $ref file includes / overlay overrides -> [ext-foundry]: wire $ref file includes + overlay overrides for separate-services azure.yaml #8775.
• Skill + routine real targets -> addressed in feat: carry Foundry agent and resource definitions in azure.yaml #8779.
• Built-in Bicep / provision-less project creation (separate RFC).

Related

Follow-up to #8590 / #8675:

• [ext-agents]: evolve azure.ai.agent to service-level shape, retire agent.yaml, add migration #8773 — agent shape + migration
• [ext-foundry]: make project/connection/toolbox Foundry resources real service targets #8774 — project/connection/toolbox real service targets (this issue)
• [ext-foundry]: wire $ref file includes + overlay overrides for separate-services azure.yaml #8775 — $ref file includes

[huimiu]

Implementation note from PR1 (#8779)

While flattening the agent definition to service-level properties in PR1, a resources key/type collision surfaced that PR2's sibling resource extensions should be aware of:

• ServiceTargetAgentConfig uses resources []Resource (the agent's attached tool resources), while ContainerAgent uses resources for CPU/memory.
• PR1 resolved it by carrying CPU/memory under a container key and omitting it from the inline agent definition struct.

When PR2 wires the real per-resource service targets (especially anything parsing container/compute settings), keep this resources disambiguation in mind so the inline azure.yaml shape stays consistent across resources.

Context: stacked on #8675; agent flat-shape (spec §1.1/§2.1) landed in #8779, $ref resolver + write helper in #8777.