Fixes Issue #530

Summary

The built-in wait_for_condition wait strategy has never been usable, and the bug hiding behind it would silently corrupt results once the surface error was fixed. This fixes both, together.

Root cause

1. Type mismatch — the built-in strategy can't be used at all.
   create_wait_strategy returned a WaitDecision (attribute should_wait), but wait_for_condition consumes a WaitForConditionDecision (attribute should_continue). Passing the built-in strategy into a WaitForConditionConfig failed on the very first poll:

AttributeError: 'WaitDecision' object has no attribute 'should_continue'

Nothing in the tests or examples routed create_wait_strategy into a config, the shipped example hand-wrote its own strategy, so this stayed latent. The JS and Java SDKs return the correct decision type.

2. Exhaustion silently succeeds.
   When polling attempts run out, the strategy returned a "stop" decision. Once defect feat: add initial operations #1 is fixed, that maps to should_continue=False, which the executor treats as success, completing with whatever partial state it happened to hold. JS throws Error and Java throws WaitForConditionFailedException at this point. Fixing only the type would have converted today's loud crash into a silent wrong result, which is why both are addressed here.

Breaking change

Executions that previously exhausted their polling attempts and completed "successfully" with partial state now fail with WaitForConditionError. This is the correct behavior and matches the other SDKs. Landing in v2; to be documented in the migration guide.

Testing

• New regression guard: the built-in strategy wires into a WaitForConditionConfig and returns the consumed type (closes the gap that let defect feat: add initial operations #1 ship).
• Condition met on the final attempt still succeeds.
• Both exhaustion surfaces covered:
  • Live raise: strategy raises → durable FAIL checkpoint carrying error_type == "WaitForConditionError" → WaitForConditionError propagates.
  • Replay: the FAILED checkpoint short-circuits the next invocation, surfacing as CallableRuntimeError with error_type == "WaitForConditionError" (typed reconstruction on replay lands with Consolidate error handling #120; asserting on error_type keeps the test stable across that change).
• Full suite: 1381 passed · ruff + format clean · mypy clean.