Expose sticky replay metadata in workflow poll responses #312

Problem

Published Server 2.5.9 routes workflow tasks using durable sticky affinity, but
the workflow poll response omits sticky_worker_id, sticky_until and
sticky_replay_mode. The bridge and leased task contain those fields. External
SDK workers cannot observe sticky_hit_expected or forced cold replay.

Reproduced against the published image digest
sha256:11c11e11498b63e644d906e43f49810a1bc0b5298f750734fe0edb279c622bca
while implementing Python affinity parity in durable-workflow/.github#124 and
durable-workflow/sdk-python#102. A 1,200-side-effect workflow completes correctly
through three signal boundaries, but all four HTTP tasks omit the replay mode
while the durable task records show sticky_hit_expected. The worker therefore
downloads the complete history instead of reusing retained middle pages.

Acceptance

• Project the authoritative sticky worker identity, expiry and replay mode into
  ordinary, retried and replacement workflow poll responses.
• Prove cold, warm and forced cold response modes through actual HTTP feature
  tests, including pagination and the existing poll request identity path.
• Preserve lease fencing, durable history and older workers' behavior.
• Publish a qualified Server patch and verify that exact image with the Python
  warm history and recovery scenarios before claiming Python sticky support.

This fixes an existing response gap. It does not change cache or affinity
semantics, and makes no Cloud rollout or capacity claim.