Keep the body scrape for reserved message types and an empty receipt id marker

AGENTS.md

@@ -202,12 +202,13 @@ exactly 140.
   Message type `MC_DELIVERY_RECEIPT` (0x04) makes it a receipt whatever the body parses to, so a
   receipt in a format `dlrFromPdu()` cannot read reaches `dlr` with `smsId` undefined instead of
   arriving as an inbound SMS. Any other named type — delivery or user acknowledgement, conversation
-  abort, intermediate notification — is not a receipt and its body is not scraped. Message type 0
-  keeps the scrape: SMSCs that send text-only receipts leave `esm_class` at 0, and reading that as
-  the spec's "default message type" would lose every one of them. A `receipted_message_id` TLV marks
-  a receipt on the same footing where the message type is 0, since nothing but a receipt carries one.
-  What gets scraped is the decoded `short_message` with any UDH stripped, so a concatenated receipt
-  is read like any other.
+  abort, intermediate notification — is not a receipt and its body is not scraped. A message type of
+  0, or one of the ten the spec reserves, keeps the scrape: SMSCs that send text-only receipts leave
+  `esm_class` at 0, and reading that as the spec's "default message type" would lose every one of
+  them. A non-empty `receipted_message_id` TLV marks a receipt on the same footing there, since
+  nothing but a receipt carries one. What gets scraped is the decoded `short_message` with any UDH
+  stripped; receipts never reach the reassembler, so an SMSC that splits one across segments gets a
+  `dlr` per segment rather than one merged report.
   The `message_state` TLV is authoritative only where it names a state in the table — SMPP reserves
   0x80-0xFF for MC-vendor-specific values, so an unnameable one keeps its raw `statusId` and leaves
   `statusMsg` to the body.