Add deployment preview support for all built-in service hosts

[vhvb1989]

Context

#10055 added the experimental extension SDK contract for service-target deployment preview. The next step is to make
azd deploy --preview useful for the service hosts built into azd, rather than leaving preview unsupported or producing
no meaningful result unless an extension implements it.

Related:

• feat: add service-target deployment preview SDK contracts #10055
• [azure.ai.agents] Support --preview / dry-run for hosted agent deploy #8549

Goal

Add a read-only, core-native deployment preview for every valid built-in service host returned by
project.BuiltInServiceTargetKinds().

The initial preview does not need to compute a detailed configuration diff. It should resolve the real Azure target and
describe, in plain language, what azd deploy would do and where it would do it.

Example:

Deployment preview

  Service `web` will deploy a ZIP package to Azure App Service `app-web-prod`
  in resource group `rg-contoso-prod`.

  Note: No previous deployment was found. This appears to be the first deployment.

For a container deployment:

Deployment preview

  Service `api` will build and publish a container image, then create a new revision
  of Azure Container App `ca-api-prod` in resource group `rg-contoso-prod`.

Built-in host checklist

The checklist intentionally follows project.BuiltInServiceTargetKinds(). Internal-only
containerapp-dotnet is not a valid azure.yaml host, and the retired springapp host is not in scope.

• appservice
  • Resolve the real Web App and optional deployment slot.
  • State whether deploy will upload a ZIP package or update the configured container image.
  • Example: Service web will deploy a ZIP package to Azure App Service app-web-prod in resource group rg-prod.
  • When a slot is selected, include it: ... to slot staging of Azure App Service app-web-prod ....
• containerapp
  • Resolve the existing Container App or Container App Job when present.
  • State whether deploy will create a new Container App revision, update a Container App Job image, or run the
    configured revision deployment module.
  • If delayed provisioning will create the target during deploy, say so instead of displaying an empty resource name.
  • Example: Service api will publish a container image and create a new revision of Azure Container App ca-api-prod in resource group rg-prod.
• function
  • Resolve the real Function App.
  • State whether deploy will upload a ZIP package or update the configured container image.
  • Example: Service jobs will deploy a ZIP package to Azure Function App func-jobs-prod in resource group rg-prod.
• staticwebapp
  • Resolve the real Static Web App and production environment.
  • State that the built output will be deployed to the production environment.
  • Example: Service web will deploy its built output to the production environment of Azure Static Web App swa-web-prod in resource group rg-prod.
• aks
  • Resolve the real AKS cluster and Kubernetes namespace.
  • State which configured mechanisms will run: Helm releases, Kustomize, and/or Kubernetes manifests.
  • Example: Service api will apply Helm and Kubernetes manifests to namespace contoso in AKS cluster aks-prod in resource group rg-prod.
• ai.endpoint
  • Resolve the real Azure Machine Learning workspace and online endpoint.
  • State which configured assets will be created or updated: flow, environment version, model version, online
    deployment, traffic, and removal of superseded deployments.
  • Example: Service model will update online deployment blue for endpoint recommendations in Azure Machine Learning workspace ml-prod in resource group rg-prod.

First-deployment note

Use live resource state, not missing local environment values, to determine whether this is the first deployment.

Represent the result internally as tri-state:

• true: azd can confidently determine that no prior deployment exists.
• false: azd found prior deployment state.
• unknown: the service API does not expose a reliable signal or the signal cannot be read.

Only print the first-deployment note when the value is confidently true. Do not claim that a deployment is the first
one merely because azd has no cached deployment state.

Possible host-specific signals include:

• App Service / Function App: deployment status or deployment history is absent.
• Container Apps: the target does not exist, or an existing app has no latest revision.
• Static Web Apps: the production environment/build does not exist.
• AKS: the configured Helm release or expected Kubernetes workload does not exist in the target namespace.
• AI endpoints: the online endpoint or configured online deployment does not exist.

If a host cannot determine this safely, omit the note.

Proposed result shape

Use one common result model for built-in and extension-provided previews so terminal and JSON formatting do not need
host-specific branches:

{
  "services": [
    {
      "name": "web",
      "host": "appservice",
      "operation": "zipDeploy",
      "message": "Service web will deploy a ZIP package to Azure App Service app-web-prod in resource group rg-prod.",
      "target": {
        "subscriptionId": "...",
        "resourceGroup": "rg-prod",
        "resourceType": "Microsoft.Web/sites",
        "resourceName": "app-web-prod"
      },
      "firstDeployment": true
    }
  ]
}

Omit firstDeployment from JSON when it is unknown rather than serializing an unsupported guess.

Behavior and implementation constraints

• Preview must be read-only. It must not run deployment hooks, build, package, publish, push images, apply manifests,
  create revisions or versions, update traffic, mutate environments, or persist deployment state.
• Resolve targets through the same ServiceManager.GetTargetResource and target-specific resolution paths used by
  normal deployment so the preview names the actual resource.
• Derive the planned operation from effective service configuration and live target properties where needed.
• Built-in targets should use a small optional core interface alongside project.ServiceTarget; they should not be
  routed through the extension gRPC protocol.
• A mixed project should return one result for every selected service. A failure to preview one built-in service must
  be explicit and must not be reported as "no changes."
• Keep output on the injected writer and support --output json.
• Do not expose secrets, environment values, image registry credentials, deployment tokens, or credential-bearing
  URLs.

Acceptance criteria

• Every host in project.BuiltInServiceTargetKinds() has a preview implementation.
• Adding a future built-in host causes a test failure until preview support is added or explicitly exempted.
• Terminal output identifies the service, planned operation, real Azure resource name, resource type, and resource
  group.
• The first-deployment note is based on live state and appears only when confidently known.
• JSON output uses a stable shared schema and distinguishes unknown first-deployment state.
• Preview performs no build, publish, deployment, hook, or persistent-state mutation.
• Unit tests cover each host, first deployment, existing deployment, unknown deployment state, target-resolution
  failure, and secret redaction.
• Command help and deployment-preview documentation describe the built-in coverage and limitations.