Read a receipt reporting a transient state as non-final too, so the merge waits for the real one

AGENTS.md

@@ -289,6 +289,16 @@ Grouped by what each one constrains.
   0x80-0xFF for MC-vendor-specific values, so an unnameable one keeps its raw `statusId` and leaves
   `statusMsg` to the body.
 
+- **A report is final unless its `esm_class` or its state says otherwise, and only `ENROUTE` and
+  `SCHEDULED` say otherwise.** SMPP 3.4 Appendix B lists every other receipt state as final,
+  `UNKNOWN` and `ACCEPTED` included, so a peer writing `ACCEPTD` for a carrier-accepted step is taken
+  at its word. Rejected: reading `UNKNOWN` as non-final, which leaves a peer whose receipt body this
+  library cannot read with no `messageDlr` at all — goal 2 wants that reported as undetermined, not
+  withheld. Both spellings resolve into `Dlr.intermediate` at the boundary rather than being read a
+  second time in `DlrMerger`, so the library cannot answer the application one way and conclude the
+  other; this library's own `sendDlr('ENROUTE')` goes out as an ordinary receipt, which is where the
+  two would first disagree.
+
 - **`smsIdFormat` names a notation per place, and normalisation never reaches inside a `<base>-<n>`
   id.** An SMSC may answer `submit_sm_resp` in hex and write the receipt's `id:` in decimal, so one
   transform over both sides cannot make them equal. `submitResp` covers the `receipted_message_id`