NR spotted a read-compat gap while verifying TEST 8 byte-diff
regions: when a Squish base was written by HPT (or any tosser
that places SEEN-BY / PATH inline in the message body rather than
in the SMAPI CtrlInfo area), consumers reading via mb.api got
attr.seen-by / attr.path empty and the raw kludge lines embedded
in Uni.Body.
SquishToUni was calling ParseCtrlInfo on s.CtrlInfo (which catches
writer-emitted-to-CtrlInfo metadata) but nothing equivalent on
s.Body. Fix: SplitKludgeBlob(s.Body, plainBody, attrs) after the
ParseCtrlInfo call -- same pattern mb.fmt.msg.uni already uses for
always-inline-kludge situations.
Either placement now populates the attribute bag; Uni.Body is
always pure user text. CtrlInfo-borne values are extracted first;
if the same key also appears in body epilogue the values
concatenate with #13 via AppendAttr -- no legitimate writer does
this, but the semantics are safe.
Test: test_consumer_round1.TestSquishHptBodyEpilogue writes a
Squish message with MSGID in CtrlInfo and SEEN-BY/PATH in the body
epilogue via the low-level API, reopens via mb.api, asserts all
three attrs populate and body is plain text.
Thanks to NR for catching this during TEST 8 verification.
Ken Johnson
287383dc6d