feat: [5/6] add reserved payload cleanup worker tasks

[wangbill (YunchuWang)]

Summary

What changed?

• Add worker-only cleanup orchestration and reserved fetch/delete/report activities while keeping phase 4 DTOs independent of the runner.
• Retain the original state machine: five-cycle continue-as-new, delivered/buffered configuration draining, interruptible durable idle, unsupported-backend waiting and bounded retry policy.
• Delete chunks of 50 with four activity waves and eight concurrent deletes per chunk, preserve positional tombstone correlation, classify terminal/retry/quarantined results safely and enforce RPC/store deadlines.
• Register reserved tasks only for payload-enabled workers, augment nonempty filters with wildcard versions, bypass business version policy for internal tasks and reuse the current authenticated channel.
• Carry original cleanup worker tests and an isolated loopback test that additionally verifies fetch/report follow a replacement effective sidecar stub.

Why is this change needed?

• Phase 5/6 of the requested large-payload implementation split. This PR's base is phase 4's branch, so its diff excludes previously reviewed phases.
• Behavioral reference: durabletask-dotnet 91739687. The complete stack preserves the original implementation at c9b53fcb3ab8585c4b3b22f9c0500cc9dd122c5a, with the documented instance-kind routing correction.

Issues / work items

• Resolves: N/A (user-requested phased feature review).
• Related: original oversized PR #387. It is preserved while the coordinator verifies this replacement stack.

---

Project checklist

• Release notes are not required for the next release
  • Otherwise: Notes added to CHANGELOG.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: No intentional API break in this phase; the payload feature remains opt-in.
    • Migration guidance: Do not release partial phases. Merge the stack in order and publish the completed core before dependent packages.

---

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: This phase's source, regression tests, and directly related metadata/documentation.
• What you changed after AI output: Split the implementation along independently buildable boundaries; retained focused regression evidence and removed unrelated formatting-only changes. Human review is still required.

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 human attestations are intentionally left unchecked.

---

Testing

Automated tests

• Result: Passed locally for this phase, without later-phase files.
• npm ci --offline --no-audit --no-fund — passed after the missing compiler was established.
• npm run build and npm run lint — passed independently without release/example/consumer-phase files.
• npm run test:unit -w @microsoft/durabletask-js -- --runTestsByPath test\payload-purge-client.spec.ts test\payload-purge-worker.spec.ts test\payload-purge-worker-transport.spec.ts test\work-item-filters.spec.ts test\worker-startup.spec.ts test\worker-versioning.spec.ts test\payload-transport.spec.ts — passed 134 tests in 7 suites.
• npm run test:unit -w @microsoft/durabletask-js-azuremanaged -- --runTestsByPath test\unit\worker-builder.spec.ts test\unit\payload-builders.spec.ts — passed 13 tests in 2 suites.
• Token-level comparison verified the extracted cleanup runner state machine exactly matches c9b53fc.
• git diff --check yunchuwang-payload-phase-4-client...HEAD — passed.
• Hosted CI: pending/not inferred. Existing main-base filters mean some workflows will not run for stacked PRs; no workflow triggers were broadened.

Manual validation (only if runtime/behavior changed)

• Environment (OS, Node.js version, components): Windows, Node.js v24.14.0; loopback gRPC with deadlines/metadata and effective-stub replacement assertions; deterministic generator/replay tests.
• Steps + observed results:
  1. Materialized this phase on its declared predecessor, with no future-phase imports.
  2. Ran the exact owning checks above and inspected the incremental patch.
  3. Kept the original feature branch/history and primary user checkout unchanged.
• Evidence (optional): Full local logs are session artifacts, not repository changes.

---

Notes for reviewers

Merge order	Phase	PR	Base branch
1	Core contracts	#388	main
2	SDK integration	#389	yunchuwang-payload-phase-1-core
3	Azure Blob provider	#390	yunchuwang-payload-phase-2-sdk
4	Purge protocol/client	#391	yunchuwang-payload-phase-3-blob
5	Purge worker	#392	yunchuwang-payload-phase-4-client
6	Release/usage/consumers	#393	yunchuwang-payload-phase-5-worker

Merge 1 → 2 → 3 → 4 → 5 → 6. Each PR targets its predecessor; retarget the next PR only after its prerequisite merges. Do not publish packages or describe a partial phase as the complete feature.

• The runtime is now feature-complete, but package publishing and final aggregate usage/consumer checks remain explicitly gated on phase 6.
• Internal JSON retains the pinned .NET PascalCase shapes. The runner import was separated from client DTOs without changing replay actions.
• Ownership proof and ETag checks remain in the phase 3 provider; this phase owns backend-safe outcome classification and scheduling.
• Full live DTS/mixed-.NET execution has not been run locally (Docker daemon unavailable). The final phase records aggregate local Blob/Azurite, source/wire interoperability and packed-consumer evidence without claiming absent hosted checks.