Add large-payload tombstone fetch and purge-result RPCs for blob auto-purge

[wangbill (YunchuWang)]

Summary

Adds the authoritative proto contract for the large-payload blob auto-purge feature. This is the source-of-truth definition that the other PRs vendor locally and re-sync from once this merges:

• SDK: microsoft/durabletask-dotnet #758
• DTS backend: AAPT-DTMB #16368738

The definitions here are byte-identical to the canonical contract shared with durabletask-dotnet #758.

Context

When an orchestration payload exceeds a threshold it is externalized to Azure Blob Storage and a token is persisted in the backend's SQL Payloads.Text column instead of the payload bytes. Purging the orchestration removes the SQL state, but the backend cannot delete the blob because it does not hold the customer's storage credentials, so the blob is orphaned.

Fix: the backend keeps the durable cleanup work and hands it to a worker that does have storage credentials. The backend records a tombstone for each externalized payload leaving live state; the worker fetches a bounded batch of due tombstones, deletes each blob, and reports the outcome of every attempt. The backend then resolves, reschedules, or quarantines each row.

Change

Edits only protos/orchestrator_service.proto. Nothing is added to the backend-facing service: the backend serves both services on one endpoint and the worker already reaches TaskHubSidecarService there, so authorization stays identical to the existing worker stream.

Opt-in on the existing handshake — google.protobuf.BoolValue large_payload_auto_purge_enabled = 12 on the existing GetWorkItemsRequest. GetWorkItems is already task-hub scoped and authenticated, so the setting binds to that task hub without a new RPC. This is a setting, not a WorkerCapability: WORKER_CAPABILITY_LARGE_PAYLOADS means a worker can resolve externalized payloads, not that the customer opted into deleting them. A repeated capability enum is presence-only and could never express an explicit false, so it could not turn the feature off.

Two bounded unary RPCs, placed immediately after GetWorkItems:

RPC	Purpose
GetLargePayloadTombstones	Hand the worker a bounded, deterministically ordered batch of due tombstones
ReportLargePayloadPurgeResults	Record the outcome of each attempt; the backend owns retry scheduling

Dispositions — exactly three: DELETED, RETRY, QUARANTINED. The split is by whether a failure can self-heal. There is deliberately no Discarded: it was success-shaped and destroyed evidence.

No reason or error-code fields - disposition is the only outcome field on LargePayloadPurgeResult. Earlier revisions of this PR also carried a LargePayloadPurgeReason enum and a storageErrorCode string; both were removed because they were write-only. The backend persists them, but no SELECT, WHERE, API, or alert reads either one, and every backend action branches on disposition alone. Failure detail already lives in the worker's telemetry at full exception fidelity, where a row is correlated by (partitionId, instanceKey, payloadId), so the fields were a lossy copy nobody queried. No reserved statements were added: these messages have never shipped in a release, so no deployed peer has ever seen field 6 or 7. disposition stays at field 5 rather than being renumbered to close the gap.

revision — carried on both the tombstone and the result as a compare-and-swap guard, so duplicate or stale reports are no-ops without a per-row lease.

Tokens — documented as blob:v2:{fullBlobUrl}. Legacy v1 tokens are never tombstoned: v1 carries a container name but not the storage account, so a delete cannot be verified against the configured account. The backend hard-deletes v1 payload rows instead, and a v1 token reaching the worker is an invariant violation that is quarantined rather than discarded.

Supersedes the earlier shape

This replaces the previous draft contract, which is fully removed rather than extended:

• GetTombstonedPayloads / AckPurgedPayloads → renamed and reshaped. The old pair was a fetch plus a bare identity-only ack, which cannot distinguish success from an unfixable failure and left retry scheduling ambiguous.
• Messages TombstonedPayload, PayloadPurgeAck, GetTombstonedPayloadsRequest, GetTombstonedPayloadsResponse, AckPurgedPayloadsRequest, AckPurgedPayloadsResponse → removed.
• protos/backend_service.proto → reverted; it is now byte-identical to main.

Because none of the related PRs has merged, this is not a compatibility constraint.

Verification

• git diff origin/main -- protos/backend_service.proto is empty.
• Field 12 was previously unused in GetWorkItemsRequest (which used 1, 2, 3, 10, 11); no field number collides.
• google/protobuf/wrappers.proto was already imported; no duplicate import added.
• All three protos compile with protoc (no errors; the only warnings are pre-existing unused imports in backend_service.proto). Descriptor introspection confirms the field numbers, RPC wiring, and enum values, and that no removed symbol survives.

No language stubs were regenerated: this is a proto-only repo (SDKs consume the protos via git submodule and generate code at build time into gitignored build/ dirs; no generated stubs are checked in).