NR asked (Message 11 in the joint inbox) for a way to round-trip
TSquishMessage.Replies[1..MAX_REPLY] through the attribute bag so
nr.linker can retire its nr.msgbase.squish.pas and write reply-
chain metadata via mb.api like it already does for JAM and SDM.
Mirror JAM's naming for uniformity across formats:
squish.replyto -- parent (scalar; existed already)
squish.reply1st -- first child (scalar, = Replies[1])
squish.replynext -- remaining chain (list, = Replies[2..MAX_REPLY])
JAM's `replynext` is a single longint because JAM walks a linked
list sibling-to-sibling. Squish stores all direct children on the
parent, so `replynext` here is a LIST attribute (via TMsgAttributes
GetList/SetList). Same key names, shape reflects the on-disk
truth -- consumers that only care about the primary reply hit the
scalar on both formats; consumers that need the full chain
(nr.linker) call GetList on Squish and walk sibling records on JAM.
SquishFromUni now rebuilds Replies[] from these keys instead of
unconditionally zeroing the array, closing the write-side drop
that blocked NR's migration.
ClassSupportedAttributes advertises the new keys alongside the
existing `squish.umsgid`.
Test: test_consumer_round1.TestSquishReplyChain -- writes a
message with reply1st=101 and replynext=[102,103,104], closes,
reopens, reads, and asserts the full chain survives.
Ken Johnson
9176b64e8b