wait_for_condition: two serdes round-trip inconsistencies

In wait-for-condition-handler.ts, the first run sees different values than replay because it skips the serdes round-trip the checkpoint/resume path uses.

**Issue 1:** initialState not round-tripped before the first check
First poll uses currentState = config.initialState (raw); resumes deserialize from the checkpoint. So the first check sees a different shape than later polls.

Fix: serialize + deserialize initialState through the serdes before the first check. Also surfaces non-serializable initialState immediately instead of on first resume.

**Issue 2:** success path returns the object passed to waitStrategy, not the checkpointed value
```
const decision = config.waitStrategy(deserializedState, currentAttempt);
if (!decision.shouldContinue) {
await checkpoint.checkpoint(stepId, { ... Payload: serializedState, ... });
return deserializedState; // waitStrategy may have mutated this
}
```
waitStrategy is user code and can mutate deserializedState. We checkpoint serializedState (captured before waitStrategy) but return the possibly-mutated object, so: (1) first run diverges from replay (replay deserializes from the checkpoint), and (2) the returned value differs from what was persisted.

Fix: deserialize serializedState again after checkpointing and return that, so the return value matches what was stored and is identical on first run and replay.

Update the docs repo to reflect these changes.

Start in wait-for-condition-handler.ts by tracing the initial poll and the success path through serialization, deserialization, and checkpointing. Verify that the first check and returned value use the same checkpointed representation as replay, then update the docs repo to describe the changed behavior.

Written by the indexing model from the issue text.