* Regression tests for a receipt body read under a data_coding it is not written in
* Read a delivery receipt's body as the octets that arrived, not by its data_coding
* Assert SMPPSim's UCS2 receipt body parses like every other segment's
* Record the receipt-body defect as fixed
* Retain a multipart segment's octets once, not twice
* Sort the new type import into its file's order
* Regression tests: a PDU the codec cannot read costs that PDU, not the link
* Refuse a single unreadable PDU instead of the whole link
* smscsim interop asserts the first attempt gets every DLR
* Record the smscsim sequence number defect as fixed
* One framing rule and one response-command lookup, per the architecture review
* Apply the stability review's nits: honest sessionError docs and one link-survives assertion
maxDelay bounds the wait and sets the bar a link must clear, and only the
first was documented, so tuning it up quietly lengthened every recovery.
The unreadable PDU the tests write is one named constant now.
A bind that returns is not proof the link works: an unreadable stream is
only found afterwards, so resetting the delay there handed a link that
died on arrival a fresh minDelay every cycle — one connect and bind per
second forever, which is how an account gets blocked for bind flooding.
The loop resets only once a link has outlasted maxDelay.
Also covers the unreadable stream that has no loop to retry it.
`close` fires only where nothing will bring the session back; a drop the
reconnect loop will retry is `disconnected`, pairing with `reconnected`.
`minDelay: 0` never doubles, so the backoff never started — both delays
are range-checked now, and only `false` spells reconnect off.
lilleman