2.20.3

• Rollback, embedded Workflow package: 2.20.3 changes no schema, history
  event or public API. Rolling back restores the shared-cursor, empty
  receive replay and fake task-drain precision bugs. A kept stream now
  records receives at the current step. Earlier versions look them up at the opening step and can replay
  those runs differently after rollback.

• A message on one stream stays receivable until it is consumed or expires
  (#1011). The run's message cursor is shared by signals, updates and every
  stream, so a signal, an update or a receive on another stream used to move
  it past older pending messages, and inbox()->receive(), peek(),
  pendingCount() and hasPending() no longer returned them. They now read
  every pending message of the stream, in sequence order.

  • After upgrading, workflow code can receive messages that earlier
    releases hid. They are the stream's oldest pending messages, so a
    workflow that receives in a loop gets them first.
  • A receive replayed from history still returns what that step consumed,
    and a replayed receive whose original call found nothing returns nothing
    again. It no longer reads the stream at a step history has passed. So a
    run where an earlier release's cursor hid a message keeps the result it
    had, and receives the message at a later step instead of consuming it at
    the old one. An update handler that runs for the first time still
    receives, even when its update is recorded at an earlier step than the
    one the run waits at.
  • A receive through a stream kept in a property records its consumption
    at the step the code is at, not the step the stream was opened at, so
    its replay matches too. Consumptions that earlier releases recorded at
    the opened step still replay.

• WorkflowStub::runReadyTasks() now drains fake-workflow tasks at their
  exact due time, including fractional seconds (#1026). It compares the
  sampled clock using the configured task model's persisted precision.
  SQLite previously skipped tasks due at that instant because it compared
  their fractional timestamps with a whole-second query value. Future
  fractional deadlines remain pending until they are due.

• Known limitation (#1024): a query can return nothing for a message an
  update handler received, because the query replays the handler at the
  wrong step. The query changes no message rows. The workflow's own replay
  and completed output still return what the handler received. This issue
  predates 2.20.3 and remains open.

Full changes: 2.20.2...2.20.3