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 Java 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 migrates Java's by_framework:trace:* history (shared format with Python, but that's a separate migration executed in Python's own Phase 2b issue — don't assume one script covers both languages). TS's historical trace namespace is unrelated and handled in TS's own Phase 2b issue.

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 the worker admin state key (the one without a TTL) that rewrites its content under the new key name
• Trace key migration scoped and executed as its own step, covering Java'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 Java workers/clients
• Old v1 keys confirmed cleared or naturally expired post-migration-window

Blocked by

#9