Summary

azd records the IaC provider (bicep / terraform / ...) via the infra.provider telemetry
attribute, but today it is only emitted by azd infra generate / synth. The provision, up,
and down commands do not emit it, so telemetry can't distinguish whether a provisioning run
used Bicep or Terraform.

Details

fields.InfraProviderKey (infra.provider) is set in exactly one place today:

• cli/azd/cmd/infra_generate.go — tracing.SetUsageAttributes(fields.InfraProviderKey.String(provider))

For provisioning, the provider kind is already resolved in a single, provider-agnostic choke point:

• cli/azd/pkg/infra/provisioning/manager.go → Manager.newProvider() — providerKey holds the
  concrete kind after applying azure.yaml's infra.provider (or the default provider resolver).

Since Manager.Initialize → newProvider runs for provision, up, and down, emitting a usage
attribute there flows onto those command spans via the existing usage-attribute mechanism
(cmd/middleware/telemetry.go).

Proposed change

In Manager.newProvider, once providerKey is resolved, add:

tracing.SetUsageAttributes(fields.InfraProviderKey.String(string(providerKey)))

This mirrors the existing infra generate pattern and introduces no new telemetry field.

Scope / notes

• Covers provision, up, and down (all route through Manager.newProvider).
• deploy is out of scope: it does not instantiate the provisioning manager and does not resolve an
  IaC provider.
• Multi-layer provisioning calls Initialize per layer; setting the same usage attribute repeatedly
  is harmless (last write wins).

Acceptance criteria

• provision, up, and down command telemetry include infra.provider with the resolved provider kind.
• The value matches the provider actually used (bicep, terraform, arm, or a custom/alpha provider).
• No new telemetry field is introduced; the existing fields.InfraProviderKey is reused.