I can queue the completions and release them from the test. Added two attempts for one housing. The old completion still marks the newer row complete.

Check which lookup selects that row. Does the handler use the event identity or whatever the screen calls current?

It uses the currently selected attempt after parsing the event. The event has its own attempt identity but the update ignores it. I have a failing assertion on both rows now.

Also assert what does not happen: no new dispatch, no second completion notification and no count change on duplicate delivery. Correcting the row lookup need not correct all its side effects.

Lookup repaired. Old event changes only its matching row, and the new row stays pending. Duplicate still emits the completion notification twice, which your extra assertion caught.

Is notification state saved, or only remembered until the application closes?

Previously only in memory. Developer has tied the report update and notification record to the durable attempt transition. Reopen with the same event now leaves one completion and one notification record in the test.

Include a completion whose identity is not in the saved set. It should not be attached to the newest row just to avoid dropping it

Unknown identity is retained as unmatched, with no row completion or dispatch. Controlled old/new, duplicate and reopen sequences all pass. This closes the offline handler fault; installed-interface testing remains separate.

Thanks for returning with the duplicate result too. That is the kind of visible annoyance the operator notices even after the developer says the right row changed.