Revisiting the RAM signature stamping knowing what I know now, I can better see what's going on and record that knowledge.  The RAM stamping routine now looks like this:

F723             ; stamp 'ram valid signature' on RAM page 0 and 3
F723             stampRAMsignature_F723:
F723 18 CE 01 00     ldy     #unk_100
F727 8D 0F           bsr     stampRAMsignatureAtY_F738 ; store ram valid sig @ Y (without nul!)
F729 86 03           ldaa    #3
F72B BD EC 60        jsr     selectRAMPageA_EC60 ; select 32 KiB RAM page as per A
F72E 18 CE 7F DF     ldy     #unk_7FDF
F732 8D 04           bsr     stampRAMsignatureAtY_F738 ; store ram valid sig @ Y (without nul!)
F734 BD EC 79        jsr     selectRAMPage0_EC79 ; select 32 KiB RAM page 0
F737 39              rts

So, the signature is at the beginning of addressable external RAM (XRAM), at 0x0100 on whatever is the current page, and at the end of XRAM at 0x7FDF on page 3.  And that's it.  There is not checksum over RAM as I had originally guessed.  Just these stamped magic values, which happen to be a well-known text string.

This is interesting, because it suggests that page 0 is typically always selected-in.  If it wasn't, I would expect that the start of this routine would explicitly do so, perhaps make a note of the current page so as to restore it when done.  So this is something to keep in mind:  RAM page 0 is possibly always selected in, except as needed.

It is a curiousity as to why the signature starts at 0x7FDF instead of 0x7FE0, since the signature text is 32 bytes and would fit there flush to the end-of-RAM.

A related oddity is in the common 'stamp RAM signature' implementation:

F738             ; store ram valid sig @ Y (without nul!)
F738             stampRAMsignatureAtY_F738:
F738 CE F8 A5        ldx     #aThisIsTheRamVa ; "This is the RAM valid signatur2"
F73B             loop_F73B:
F73B E6 00           ldab    0,x
F73D 27 08           beq     leave_F747
F73F 18 E7 00        stab    0,y
F742 08              inx
F743 18 08           iny
F745 20 F4           bra     loop_F73B
F747             leave_F747:
F747 39              rts

The test at F73D for the nul-terminator is done prior to storing the character, so the signature string is really 31-bytes, since the terminator is not stored although space is allocated for it.  So that trailing byte will be a random value.

A further oddity is why the 'e' in signature is changed to a '2', and this may be evidence of some corporate lore we will never know.  Conceivably it could serve as a version number such that a RAM image from a prior but incompatible version of the firmware would cause the RAM to be reformatted.  However there is no provision for firmware updates.  That would only happen in the lab, since you have to open the unit and pull the ROM with a new one you burned.  The RAM is battery-backed, so this is a possible occurrence.  And this image is firmware version 2.03, so the trailing '2' digit is suggestive of this hypothesis.

But back to the 'random trailing byte'.  I would consider this a bug in a code-review, but ultimately it is masked because the signature test implementation also disregards the terminator value:

F6C6             testRAMsignature_F6C6:
F6C6 86 03           ldaa    #3
F6C8 BD EC 60        jsr     selectRAMPageA_EC60 ; select 32 KiB RAM page as per A
F6CB CE F8 A5        ldx     #aThisIsTheRamVa ; "This is the RAM valid signatur2"
F6CE 18 CE 7F DF     ldy     #ramsiglocp3_7FDF ; RAM signature location on page 3 only
F6D2             loop_F6D2:
F6D2 E6 00           ldab    0,x
F6D4 27 0A           beq     next_F6E0
F6D6 18 E1 00        cmpb    0,y
F6D9 26 1F           bne     loc_F6FA
F6DB 18 08           iny
F6DD 08              inx
F6DE 20 F2           bra     loop_F6D2
F6E0             next_F6E0:
F6E0 BD EC 79        jsr     selectRAMPage0_EC79 ; select 32 KiB RAM page 0
F6E3 CE F8 A5        ldx     #aThisIsTheRamVa ; "This is the RAM valid signatur2"
F6E6 18 CE 01 00     ldy     #ramsiglocp0_100 ; RAM signature location on page 0 only
F6EA             loop_F6EA:
F6EA E6 00           ldab    0,x
F6EC 27 0A           beq     leaveSuccess_F6F8
F6EE 18 E1 00        cmpb    0,y
F6F1 26 07           bne     loc_F6FA
F6F3 18 08           iny
F6F5 08              inx
F6F6 20 F2           bra     loop_F6EA
F6F8             leaveSuccess_F6F8:
F6F8 0A              clv
F6F9 39              rts
F6FA             loc_F6FA:
F6FA BD EC 79        jsr     selectRAMPage0_EC79 ; select 32 KiB RAM page 0
F6FD BD F7 54        jsr     setcpLine2_F754 ; set cursor Line 2
F700 CE FC D6        ldx     #aSignatureNotFo ; "(Signature not found. Initializing...)"
F703 BD F6 69        jsr     showText_F669   ; show nts text @ X
F706 BD F7 5A        jsr     setcpLine3_F75A ; set cursor Line 3
F709 86 20           ldaa    #$20 ; ' '
F70B CE 7F DF        ldx     #ramsiglocp3_7FDF ; RAM signature location on page 3 only
F70E             loop_F70E:
F70E E6 00           ldab    0,x
F710 08              inx
F711 36              psha
F712 BD F6 74        jsr     sendLCDbyteB_F674 ; send byte in B to LCD (w/ctrl as per 0x5b)
F715 32              pula
F716 4A              deca
F717 26 F5           bne     loop_F70E
F719 86 02           ldaa    #2
F71B             loc_F71B:
F71B BD F6 1E        jsr     delay590ms_F61E ; delay ~ 590 ms
F71E 4A              deca
F71F 26 FA           bne     loc_F71B
F721 0B              sev
F722 39              rts

with the loop tests at F6D4 and F6EE.

So, I think in sum there are some things that can be asserted about RAM:

• the RAM signature is stamped at the very beginning and end of all RAM, with quirks that are mirrored in the signature test.
• there is no RAM checksum (though comprehensive non-destructive R/W testing can be done through other mechanisms)
• RAM page 0 probably is always selected in, and can hold system variables, except in specific, localized cases.