NR Message 23 (v0.6.2 verification) flagged 21% of year-09
archive messages mismatching HPT by exactly N leading #13 bytes.
Root cause in mb.kludge.SplitKludgeBlob: the rejoin loop used
`bodyOut = ''` as a proxy for "haven't emitted yet", conflating
"empty string so far" with "no line committed yet". A message
whose raw body started with blank lines (leading CRs) lost
those CRs because the bodyOut-stays-empty branch fired and
suppressed the separator.
Fix: track emission with a dedicated `emitted: boolean` flag.
Once any line has been committed (empty or not), subsequent
lines always use CR as separator. Leading empty lines now
contribute their CRs to the output.
Regression test: test_fuzz_kludge.TestLeadingCrPreserved covers
leading-CR-x2, leading-CR-x1, and kludge-prefix + blank-line +
user-text mixed case.
Expected outcome on NR's re-run: the 2055 messages previously
mismatching by one leading CR and the 15 by 2-4 leading CRs
should all match HPT byte-for-byte post-fix. That pushes the
66% body-parity to ~99.5%.
Ken Johnson
f55576218b