I believe I’ve found my answer!
It was hinting at me right there in the genesis block… among the verifiable compact identities/joiners entries and even the un-compacted certifications pointer to the identity of the account being certified – which dont verify.
A question I hadn’t yet asked myself: « How could any message be verifiably signed if it contains the block hash of the block it is included in? », led me to see what BlockUID the un-compacted Identity and Membership documents used… which is 0-E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 and which is NOT the CertTimestamp of the compact certifications… which is simply 0 without -HASH; but the accounts needed something to use as blockhashes; whatever they were using looks to have used the 0-E3B0… BlockUID when creating/signing Membership, Identity and Certification… but the node that forged the genesis block compacted the certification entries using the ‹ 0 › as BlockUID. Simply editing the CertTimeStamp to use the same value as the IdtyTimestamp creates a Certification document which is verifiable against its given bottom signature and Issuer pubkey. [note: ive edited my conclusions above in the past hour]
[and after a couple of hours of « Where does the hash for the identity/membership docs come from? » I realize… its the sha256 of an empty message. Very clever guys!
[added following morning: compact certs never have a blockhash expressed, only the block-num.]