Redrive doesn't move the failed run's pending inbound messages to the successor #1013

Problem

Redrive copies the source run's message cursor to the successor (MessageStreamCursor::transferCursor), but not the source's pending inbound messages. An inbound row keeps the workflow_run_id of the run that was current when it arrived. inbox()->receive() in the successor reads only rows with the successor's workflow_run_id. So a message that was still pending on the failed source at redrive time is never received by the successor.

Continue-as-new handles this with MessageService::transferMessagesToContinuedRun(). Redrive has no equivalent.

Reproduction

The workflow awaits go, receives one message from chat, runs an activity, sends a reply, then runs a failing activity.

1. Signal go, send m1, and run the tasks. The run consumes m1, then fails.
2. Send m2. It lands on the failed source run as pending.
3. Redrive.

The successor finishes, and m2 stays pending on the source run. A successor that receives again at a later step gets null instead of m2.

General's interim review of #1012 found this; it predates #1012. In #1012's redrive test, the assertion that "m2 stays pending" records the current behavior. It is not a requirement.

Expected

At redrive, the source's pending inbound messages for its instance move to the successor, the same way continue-as-new transfers them. They are then received in order after the reused prefix.

Notes

• The transfer must happen in the redrive transaction, before the successor's first task.
• It interacts with the shared message cursor (Signals and other streams advance a shared message cursor and hide pending stream messages #1011).