Stopped materialized input readers still replay state

### Feature Summary

`InputPortMaterializationReaderRunnable.stop` prevents tuple replay, but the state replay loop does not check the stop flag. A reader stopped before or during replay can still deserialize and emit persisted state rows, changing downstream state after workflow cancellation.

Before: stopping a materialized reader still allows state frames to be emitted.

Expected: stopping the reader skips both state and tuple replay while still closing the channel.

Reproduction evidence:

1. Create a materialized input reader whose state document contains a row.
2. Call `stop` before `run`.
3. Run the reader and observe that one `StateFrame` is still placed on the input queue.

Version and commit evidence:

1.3.0-incubating-SNAPSHOT on main

**Commit Hash (Optional)**
50321e403c82df299a13deb50a7f9849dd93bdba

**Relevant log output**

stopped=True state_frames_emitted=1 finished=True

### Proposed Solution or Design

Expected: stopping the reader skips both state and tuple replay while still closing the channel.

### Affected Area

Workflow Engine (Amber)