I've triaged this now.
The bug happens first in 
5202:47bd81998ddc
interestingly it happens there only after the *second* sign&send call in
my application. This version has grown several db.commit() calls for
one-time key handling. Then 
5203:9f490cc0effe
grows another db.commit() and in that version the bug happens every time
for me.

My suggestion (forward recovery :-) is to add a new cursor for one-time
key and session handling. I've wanted to do this *forever* because I see
 *lots* of failing transactions due to colliding session updates in a
busy tracker. It also happens with some browsers when the browser is
restarted with lots of open windows and expired session info. So it's a
good idea to separate session and otk handling from data updates to the DB.

But first I want to create a test that reproduces the problem after I've
found out what's going on and why this doesn't happen in our tests.

My testing "framework" is quite simple: I have the database open in psql
and press "sign&send" which raises a Reject. Then I press "sign&send"
again. If this raises an assertion error a change was made to the DB
that shouldn't have gone through (Bug present). Then I undo the change
in psql and I'm ready for the next round :-)