This makes for ugly logs though probably no functional impairment.

So we'll just have a practical zero second delay

Combined with the new issuer behavior, this should not impose an
undue load on any part of the system while providing the most
responsive payment experience possible.

It gets in the way of Eliot logging.

If SpendingController develops some internal state it should really remain
internal, anyway.  Don't make _plugin.py worry about this.

just bumping CI really

removing the operation-id may not actually be an improvement ... it is a
simplification, though.  However it requires us to load all the rows into
python and then send them back to the database instead of only loading them.
I thought removing the operation-id from the in-use table would be a win and
maybe it is but not for the reason I thought - sqlite3 emits the same code
whether you do `in [foo]` or `in (select x from [foo])` as far as I can tell.

Still, I like the simplification so we'll go with it for now.

Instead of immediately extracting passes, get them and later mark up the store
with the outcome of the attempt to use them.

Parens can create a tuple or something and we don't want that.

Along with an in-memory implementation of a pass factory that works with it.