Add Workflow host conformance after IaC plugin boundary is explicit

[intel352]

Problem\nThe IaC conformance gate added for DO/AWS cannot be honestly applied here yet. Azure serves sdk.Serve(internal.New(version)), but the manifest/host boundary is ambiguous: plugin.json names the plugin azure, declares iacProvider: true, and does not expose strict typed IaC provider services or a legacy iac.provider module contract comparable to AWS.\n\n## Expected migration\n- decide whether Azure should be a legacy module plugin or strict sdk.ServeIaCPlugin typed provider\n- align plugin.json, binary name, provider discovery metadata, and runtime contracts\n- add min/current Workflow engine host conformance once the shipped boundary is explicit\n\n## Reference\nSee GoCodeAlone/workflow-plugin-digitalocean#94 and GoCodeAlone/workflow-plugin-aws#6 for the initial conformance pattern.

[intel352]

Added current wfctl plugin conformance probe result from origin/main (2026-05-11):

/tmp/wfctl-conformance plugin conformance --mode typed-iac --build-package ./cmd/workflow-plugin-azure --engine-version v0.51.3-0.20260511092920-8e4247812e6d --format json --output conformance-evidence.json .

Result:

error: iac: plugin uses legacy InvokeService dispatch removed in workflow v1.0.0

Also, released wfctl v0.51.2 strict manifest validation currently fails before executable conformance because plugin.json uses legacy boolean shape:

error: json: cannot unmarshal bool into Go struct field RegistryCapabilities.capabilities.iacProvider of type main.RegistryIaCProvider

Cutover order should be:

1. migrate manifest capabilities.iacProvider to current object shape
2. add plugin.contracts.json / strict typed config descriptor
3. replace sdk.Serve with sdk.ServeIaCPlugin + typed server wrapper
4. add push-only executable conformance CI after local typed-IaC conformance passes.

[intel352]

Antagonistic rollout review clarification:

Until this migration lands and wfctl plugin conformance --mode typed-iac passes, Azure should be treated as not registry-compatible for enforced typed-IaC evidence, even if manifest validation or future legacy host-load checks pass. The manifest capability claim and runtime protocol must match before install/registry compatibility can rely on it.

Smoke must be metadata-only: no Azure credentials, no cloud mutation, no secret/env dump, no resource Read/Plan/Apply/Destroy/bootstrap/credential RPCs.

[intel352]

Resolved via the cloud-SDK extraction + strict-contracts cutover work. Current state verified 2026-05-16:

• cmd/workflow-plugin-azure/main.go serves via sdk.ServeIaCPlugin (typed IaC gRPC contract; legacy sdk.Serve removed per strict-cutover)
• .github/workflows/iac-host-conformance.yml is in place — IaC Host Conformance gate tests against minEngineVersion + WORKFLOW_CURRENT_VERSION, matching the DO #94 / AWS docs: post-merge retro for typed-IaC conformance (PR #5) #6 pattern
• plugin.json declares minEngineVersion + iacProvider metadata

Closing as RESOLVED. The manifest/boundary ambiguity cited was resolved when azure shipped sdk.ServeIaCPlugin via the cloud-SDK extraction pipeline (workflow-plugin-azure v1.1.1 → v1.1.2 shipped 2026-05-15/16).