Keep condition replay drift recoverable and prepare Python 2.5.3

[rmcdaniel]

Change

Condition key and predicate fingerprint drift now raise NonDeterministicReplayError, including the original wait identity, workflow sequence and mismatched definitions. The worker reports a task failure without submitting fail_workflow.

Accepted updates preserve replay faults as task failures instead of permanently failing the update. Queries report unavailable state with the original replay error as their cause. Application predicate and update-handler failures retain their ordinary business-failure behavior.

The existing Server contract blocks replay failures. The documented recovery is to deploy compatible code and call await handle.repair(). This avoids repeatedly executing an incompatible deployment and resumes the original run and history.

Refs #104. Keep the issue open until exact published-package recovery and ordinary consumers are verified.

Verification

• Fourteen regression controls fail before the correction, including both new official replay fixtures.
• Final focused condition, replay corpus, query and update checks pass: 114 tests. Static analysis and lint pass.
• Local complete SDK run passes 2,563 tests, with two additional environment errors because the slim container lacks Git. Hosted complete suites are required before merge.
• Connected workflow and accepted-update scenarios pass for both changed keys and fingerprints against untouched published Server 2.5.16 (sha256:d0035cbffa5b904e5f9f7f43f84f6caf03beefc93bab8731c7e960b7a344e771). They start on an actual registry 2.5.2 producer and execute separate cold candidate processes. The incompatible condition is rejected, polling stays blocked before repair, and repair resumes the same task at attempt 2. The original run, update identity and history prefix survive. Each run completes once without WorkflowFailed, and accepted updates complete without UpdateFailed.
• The four checked-in integration scenarios run in normal CI. Initial workers register their command contracts before workflows start. An optional older registry interpreter permits publication qualification to start the history on Python 2.5.2 and recover with the exact successor. Both new official corpus fixtures fail against the installed 2.5.2 package and pass against the candidate. Source validation does not claim that an unreleased successor is already on PyPI.

Prepares the routine patch release 2.5.3. No wire, protocol or Server artifact change is required.