Enqueue reply promise after the send, not before

[henrikbjorn]

Summary

Simplifies the cancellation-safe send path merged in #13. That fix kept the reply promise being pushed onto @reply_promises before the write and added a rescue Exception to delete-and-reject it if the send was interrupted. This reorders the two lines instead — send first, then push — so the orphaned-slot state can never exist in the first place, and the rescue block is deleted.

@write_lock.acquire do
  @connection.send_data(msg)   # bytes on the wire first
  @reply_promises << promise   # then reserve the slot
end

Why this is safe in both cancellation windows

• Cancelled/failed mid-send (the incident: write blocked on backpressure, caller hangs up): send_data raises before the << runs, so no promise is ever enqueued — nothing to clean up, no orphan, no misrouting. Structurally impossible rather than defended.
• Cancelled while awaiting the reply (the common hangup): the promise is already in the queue and stays there; the reply arrives, shift.resolve fires against a promise nobody is waiting on (a harmless no-op), and the FIFO stays aligned with the wire. Unchanged from before.

The one invariant this relies on: nothing yields between send_data returning and the push (both are sequential statements inside the lock), so no reply for this command can be observed before its promise is queued. The push stays inside the write lock so queue order keeps matching wire order.

Tests

The regression tests from #13 are unchanged in intent and still pass. I verified they still fail (3/3) on the naive push-before-send ordering, so they retain their teeth against this implementation — the reorder, not the tests, is what provides safety. Full suite: 120 runs, 414 assertions, 0 failures.

Note

This supersedes the rescue Exception approach from #13 (already merged); net effect is a deletion of that block. Builds on master.