[pelikhan]

Direct Azure dependencies need testable boundaries, and the Bicep deployment needs an explicit account of which services can be exercised locally. This adds injectable service contracts and separates genuine simulator coverage from protocol fixtures and deployment-only assertions.

Approach

• Inventory all 23 resource types across the eight Bicep modules and guard their coverage against the compiled ARM template.
• Introduce owned Blob, archive ADX query, managed-identity, and hosted archive consumer interfaces. Retain existing deployment, PostgreSQL, Key Vault, and telemetry interfaces and preserve activation, HTTPS, authorization, and destination-acceptance gates.
• Add separate integration cases for Blob, Queue, Table, PostgreSQL canonical and operational adapters, archive recovery, identity/Key Vault, telemetry, ACR, Container Apps jobs, Functions configuration, and ARM planning. Wire them into the existing Linux Functions harness and CI with explicit dependency preparation.
• Handle only the exact Blob 409 BlobAlreadyExists response as an existing immutable object, then verify its contents and digest. Unrelated conflicts still fail.

Validation

• All 14 service cases passed with no skips, using real Azurite and PostgreSQL containers where applicable.
• Token broker and archive race suites, full server package tests, and focused Go lint passed.
• Root lint, 58 focused Azure/harness contract tests, shell syntax checks, and compilation of 78 workflows passed.

Coverage limitations

The Linux Functions Core Tools end-to-end harness and optional licensed Kusto engine were not executed on this macOS host. CI is wired to run the complete Functions/service harness. The optional Kusto suite requires explicit operator license acceptance.

Protocol fixtures and deployment assertions do not establish live Azure RBAC, networking, scheduling, managed monitoring, or managed-service durability. No Bicep resources, rollout policy, or generated ARM/lock artifacts are changed.