Add SDK-owned blob purge service contract and shared task integration

[wangbill (YunchuWang)]

Summary

What changed?

• Add SDK-owned Microsoft.Azure.DurableTask.LargePayloadPurge.Abstractions, an independently versioned package containing the service capability and activity transport interfaces, with a source reference to the SDK Client project.
• Keep the canonical tombstone/result records and disposition enum in Microsoft.DurableTask.Client; no model copies, moves or type forwarders.
• Make GetLargePayloadTombstonesActivity and ReportLargePayloadPurgeResultsActivity publicly constructible with a task-hub-bound ILargePayloadPurgeClient.
• Put ILargePayloadPurgeClient in the contracts assembly, preserving its namespace and signatures. The Blob implementation references the contracts package, so transport consumers do not need a reference to the Blob implementation.
• Adapt the standalone worker's existing keyed gRPC transport to that interface, preserving authentication, reconnection, deadlines, status handling and opaque correlation tokens.
• Add contract API/model-identity/signing tests and integrate the new package with the existing solution, signing, SBOM, packing and gated publication process.
• Document the optional .NET isolated Functions integration and the separate service contract.

Why is this change needed?

• The optional Microsoft.Azure.Functions.Worker.Extensions.DurableTask.AzureBlobPayloads package invokes the shared purge tasks through ordinary function bindings. Public construction and the narrow transport interface let it reuse the SDK implementation with a bound local-host bridge and worker-owned blob storage.
• The companion Functions extension and provider supply function wrappers, client binding and the authenticated service bridge. This PR changes only the shared SDK integration surface.
• Maintaining the optional service contract beside its canonical SDK models lets repository builds use a ProjectReference rather than requiring an externally published SDK model package to bootstrap compilation.

Issues / work items

• Related: Azure/azure-functions-durable-extension#3556
• Related: Azure/durabletask#1408

---

Project checklist

• Release notes are not required for the next release
  • Otherwise: Notes added to release_notes.md
• Backport is not required
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• All required tests have been added/updated (unit tests, E2E tests)
• Breaking change?
  • If yes:
    • Impact: N/A
    • Migration guidance: N/A

No breaking change for released SDK packages - the constructors and interfaces are additive relative to main.
The constants remain internal. The original bootstrap, orchestration, deletion, task names, payloads, retries
and continue-as-new behavior are unchanged.

The package preserves assembly name DurableTask.LargePayloadPurge.Abstractions, SDK signing key and planned
0.1.0 version. The service capability remains in DurableTask.LargePayloadPurge with its three required
deadline/cancellation signatures. The activity transport remains in Microsoft.DurableTask.AzureBlobPayloads
with its original two signatures and optional cancellation-token defaults. Canonical SDK model identity and
all runtime implementations are unchanged. No protobuf changes are included.

Breaking Change (unreleased prototype binaries only)

• Type: binary
• Impact: ILargePayloadPurgeClient moves from the unreleased Blob implementation assembly to the contracts assembly; no duplicate definition or type forwarder remains.
• Migration: Rebuild prototype consumers against the updated contracts and Blob packages. Source namespace/signatures are unchanged. Consumers of the earlier differently signed service-contract prototype also require a rebuild.

---

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

• No
• Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
• Yes, an AI agent generated most of this PR

If AI was used:

• Tool(s): GitHub Copilot
• AI-assisted areas/files: Contract project, tests and release integration; activity construction, transport adapter, standalone registration and documentation.
• What you changed after AI output: No human changes recorded yet.

AI verification (required if AI was used):

• I understand the code and can explain it
• I verified referenced APIs/types exist and are correct
• I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
• I reviewed concurrency/async behavior
• I checked for unintended breaking or behavior changes

These first-person attestations remain for the human author.

---

Testing

Automated tests

• Result: Passed - 7 updated contract tests and 230 extension tests, zero failures or skips. Before the move, the new export/dependency assertions failed as expected (2 failed, 5 passed); all 7 passed after the move.
• dotnet test test\LargePayloadPurge.Abstractions.Tests\LargePayloadPurge.Abstractions.Tests.csproj --no-restore --verbosity quiet
• dotnet test test\Extensions\AzureBlobPayloads.Tests\AzureBlobPayloads.Tests.csproj --no-restore --verbosity quiet
• Local Release packing passed for the netstandard2.0 contract and its SDK dependency closure, including the extension's netstandard2.0, net6.0, net8.0 and net10.0 targets. Existing analyzer warnings remain.
• The actual contracts package exports exactly IOrchestrationServiceLargePayloadPurgeClient and ILargePayloadPurgeClient, references the canonical Client models, and carries the SDK strong-name token.
• Package manifests and assembly identities were inspected. Contracts have no Blob, storage, worker or gRPC implementation dependency. All four Blob target assets reference the contracts assembly and neither define nor forward the transport interface. Core has no reverse dependency.
• Both original license texts were verified byte-for-byte in the package, with the expression Apache-2.0 AND MIT.
• Both signing pipeline definitions parse, and the new public publication selector matches exactly one approval-gated job while excluding symbol packages. Hosted signing/publication was not executed locally.
• Shared-task coverage executes actual Get/Delete/Report activities through the SDK shims and Core replay executor, checking argument envelopes, token correlation, structured failures, retry timers, external events and continue-as-new. These tests are not a Functions host/worker end-to-end run.
• Existing standalone control, named-worker transport/reconnection, deadline, versioning and filter tests remain covered.

Manual validation (only if runtime/behavior changed)

• Environment (OS, .NET version, components): Windows and .NET SDK 10.0.401 for SDK tests; a local Functions host and actual isolated worker for companion integration.
• Historical companion integration results, recorded before the contract ownership and signing-key migration:
  1. The optional package's compiled functions executed Get/Delete/Report; all four eligible owned v2 blob targets were physically absent afterward.
  2. Enablement remained task-hub-scoped. A strict-version business orchestration failed while the empty-version purge runner stayed Running.
  3. A base-extension-only application had no purge functions or runner; explicit disable followed by restart did not re-enable cleanup.
• Current SDK boundary validation consists of the 7 contract tests, 230 extension tests, source-based package builds, and package ABI/dependency-graph checks. The physical SQL/blob end-to-end run above has not been repeated for the new contract identity.
• Evidence (optional): SDK TRX/build logs are retained locally. Historical companion results are separately owned and were not independently rerun in this SDK session. They establish the earlier reported local cases, not a cloud deployment, whole-container cleanup guarantee, or a fresh physical end-to-end result for this migration.

---

Notes for reviewers

• The new package's planned initial version is 0.1.0, independent of the repository-wide SDK version. The service interface retains its Apache-2.0 notice and the activity transport interface retains its MIT notice. The package includes both original texts and declares Apache-2.0 AND MIT; no source was relicensed.
• The dependency direction is Blob implementation -> contracts -> SDK Client -> SDK Abstractions -> Core. Contracts are not BCL-only, but have no Blob/storage/worker/gRPC implementation dependency. Core does not depend on the contracts or SDK Client.
• Publish compatible Client/Abstractions packages containing the purge models before the new package. Published Client 1.26.0 lacks those models. Source builds do not need an external Client-version override; local package versions used for validation are not release claims.
• Both activity constructor paths are used: the public typed transport path by the Functions integration, and the internal generated-client path by standalone registration and existing tests.
• The purge transport, bound Functions client and payload store must target the same task hub. The integration owns their credentials, lifetime and reconnection policy.
• The original SetLargePayloadAutoPurgeAsync remains authoritative: enable sets the backend flag, deduplicates the fixed unversioned runner, verifies identity/Running status and sends the batch event; disable only writes the setting.
• Adoption requires compatible companion Functions/provider packages and the shared SDK release. No validation-only package versions or machine-local references are committed.