Consider the following:

• the %bak $side sends a %kick $boon
• the %for $side acks the %kick, and enqueues a %cork $plea; the $ack for the %kick is lost
• the %bak $side receives the %cork, and puts the flow in closing. the $ack for the %cork is lost, so the %for side doesn't put the flow in the corked set
• the %bak side resends the %kick, and the $ack for the %kick arrives, with the current logic we will interpret the %ack for the %kick as if it was a %cork, calling fo-abel and deleting the flow
• the %for side will continue sending the %cork $plea and the $bak side will no-op since the flow it's gone.

this solution adds an extra check, making sure that we are the %for side (the only one that sends %corks) when handling %acks for %corks. for peers that might have end up in this situation we check every time that there is an outstanding %cork $plea (every ~m2 on +sy-prod) if we can peek for the corked flow on the %for side.

PS: this seems to only happen if the %cork $plea arrives before the %ack, since the receiver of the $boon will drop it on the floow if the flow is in closing, and won't ack it again

PPS: i'm going to move the logic to peek for this corks to a state migration, instead of keeping this code around forever

Note: %ames regresses to the larval core on state migrations to be able to handle scrying and emitting moves on +load. with the introduction of the %mesa core, the pattern followed there has been to scry into our own %ames namespace to emit unix packets for %pokes or %acks, if this step happens during an ames migration, the logic is that any %call or %take into the %larval core will load state into the %larval gate (see +molt) when this happens we process the move that triggered %ames the vane being called, but, if we try to scry using the +roof gate, this will read data from the vane before the ames state is loaded, which means that trying to find a page for any payload we want to send (e.g. %poke or %ack) will find nothing (bunted state) and will no-op. This is only visible for +sy-prod, triggered by the /mesa retry timer, anything else doesn't use the message constructor directly (%meek, %moke and %mage tasks) deferring that to the next move processing—which is good since at that time we need to have state loaded.