A resumed session that dropped delta messages still claimed a complete
delta, and coverage.omittedMessageCount rode the full-list count into
the delta payload. resumeDelta now carries its own omittedMessageCount,
and the prompt states the delta is not complete when the cap drops a
delta message.
The recovery-outcomes select had no deterministic order, so the item
cap kept an arbitrary 30 rows instead of the newest 30. Add createdAt
and id order to that select, matching the pattern already used for
issue thread interactions.
Co-authored-by: Paperclip <noreply@paperclip.ing>
