Splitting this out of #1887 comment so it doesn't block the PR further. From there:
Since 0xMiden/node#2075, SyncChainMmrResponse carries block_signature - but it's dropped in the ChainMmrInfo, so this assumption is still fully open.
The signature doesn't make the tip canonical (a malicious validator still can't be caught - that's the "eventually… canonical" part), but it does let the client authenticate that the returned header was signed by the validator, shrinking the trusted set from any serving endpoint to the validator.
Might be worth carrying it through ChainMmrInfo and verifying before the tip leaf is added (anchor the validator key to the current trusted header), rather than leaving the assumption open - or tracking as a follow-up.
Splitting this out of #1887 comment so it doesn't block the PR further. From there: