Replay redriven memo, search-attribute and signal-wait events at their reused time #235

Follow-up to #232, from the Workflow 2.19.0 review.

Gap

Workflow 2.19.0 lets redrive reuse more completed steps:

• workflow#1001 reuses MemoUpserted and SearchAttributesUpserted.
• workflow#1002 reuses an applied signal wait: SignalWaitOpened, SignalReceived and SignalApplied.

On the successor run these events carry reused_from_run_id and reused_recorded_at. Core replays now() after them at reused_recorded_at, via RedriveReplayClock::recordedAt().

The 2.19.0 notes say service-mode SDKs are not yet qualified for these events. If this SDK takes replay time from recorded_at or timestamp on any of these five events, a redriven workflow's now() after an upsert or signal wait comes out as the redrive time, not the source run's time. #232 only covered side effects, markers, timers and start time.

Done when

• For each of the five event types, replay time prefers payload.reused_recorded_at when it is present.
• Every event type this SDK actually replays has a regression fixture. It must be a redrive successor history with the reuse keys, and it must fail before the change and pass after it. Assert per-event provenance: each named event exists and carries both keys. A combined "any reused event" check isn't enough.
• If this SDK doesn't consume one of these events for time at all, say so with a test proving it, rather than skipping it silently.
• The SDK's regression-corpus policy guards any clock file you touch.

Ships in the next minor. Security reviews the exact head before merge.