Complete Python and Rust worker-affinity parity

[rmcdaniel]

Confirmed gap

Python and Rust currently declare local_activities, worker_sessions, and sticky_execution as supported: false. This is deliberate fail-closed routing, but not feature parity with the PHP service SDK. The Embedded documentation placement also obscured the distinction; that correction is tracked separately in durable-workflow/durable-workflow.github.io#125.

Source: sdk-python/src/durable_workflow/client.py PORTABLE_WORKER_AFFINITY_CAPABILITY_MANIFEST and sdk-rust/src/lib.rs portable_worker_affinity_capability_manifest(). Both worker implementations use these declarations, with tests expecting refusal. Merely changing the flags would route unsupported work and is not a fix.

Implementation scope

Reuse the existing Server worker-affinity protocol and PHP SDK semantics. Implement language-native worker execution, not a second wire protocol.

• Python: local activity execution and recorded replay, typed worker-session lifecycle, bounded sticky execution with cold-replay fallback.
• Rust: the same three capabilities with language-native APIs.
• Qualify each implemented capability against the existing public portable-worker-affinity scenarios: local retries/timeouts/cancellation and restart; session expiry, holder loss, reacquisition and shutdown; sticky eviction, build mismatch, replacement and cold replay.
• Preserve fail-closed routing for SDK versions that lack each capability. Advertise support only after implementation and published-package qualification.
• Put runnable usage on the Python/Rust SDK documentation sites and update the service-mode support matrix after publication.

Order

Accepted SDK parity work, separate from the immediately actionable documentation correction. Implement and qualify one capability at a time; local activities first, then sessions, then sticky optimization. This is not a prerequisite for correcting misleading documentation, and the docs fix must not close this issue.