Redis cluster support Phase 2b: production key migration to v2 schema

[zhchxiao123]

What to build

Execute the production migration to the v2 key schema for the Python SDK's deployments. Decide and execute one of two migration paths:

1. Maintenance-window rebuild — deploy the new SDK version with REDIS_KEY_SCHEMA_VERSION=v2, let old v1 keys expire naturally via their existing TTLs, run a one-off rewrite script for the one key without a TTL (worker_admin state).
2. Dual-write transition period — write both v1 and v2 key names for a bridge period covering the longest TTL (7 days), read v2-first-fallback-v1, then retire v1 writes once the bridge period ends.

For trace keys specifically, this is migrating one historical namespace (Python's pre-v2 by_framework:trace:* format) — Java shares this same historical format, but TS's historical trace namespace is a separate, independent migration handled in its own repo's Phase 2b issue. Don't assume one script covers both.

Produce a rollback plan: revert REDIS_KEY_SCHEMA_VERSION to its default, valid only while old keys haven't expired or been cleared.

Acceptance criteria

• Migration path chosen (maintenance-window rebuild vs dual-write) and documented as a runbook
• One-off migration script for worker_admin (the one key without a TTL) that rewrites its content under the new key name
• Trace key migration scoped and executed as its own step, covering Python's by_framework:trace:* history
• Rollback plan documented and tested in a non-prod environment
• REDIS_KEY_SCHEMA_VERSION=v2 switched on in production for Python workers/clients
• Old v1 keys confirmed cleared or naturally expired post-migration-window

Blocked by

#43