All nodes (including full nodes) must know the chaintip of the longest chain in order to sync in a trustless manner.
That's backwards.
No it isn't.
It's backwards in the sense that nodes sync in a trustless manner to gain knowledge of the tip, not the other way around.
I wasn't following up on the pruning discussion.
Which is dependent to access to at least one honest peer. You can't fully sync if you don't have access to at least one peer that can provide you blockheaders up to the chaintip of the best chain. Maybe I worded it poorly but it was in response to this false claim.
It becomes much easier to pretend some blocks don't exist to selected targets, and get them to accept selectively rewritten history for just long enough to rip them off.
If a node has the full set of headers then it can't be tricked into thinking a block on the longest chain doesn't exist. In order for a node to obtain the full set of headers it must have at least one honest peer which also has a copy of that full set of headers.
This is independent of the number of peers have a particular block of the blockchain. Pruned nodes or a DHT node do not reduce the number of copies of the
blockheaders, they reduce the number of copies of
blocks. Full blocks are not needed to determine the longest chain in a trustless manner. If it was than SPV clients would be impossible as well.
To trick a node into thinking a 'block doesn't exist' requires an attacker keep that node from learning of one or more blockheaders. If the node has the blockheader for most recent block it know the block exists. It may not (yet) know the contents but it certainly knows it is exists. A node which knows a block exists but doesn't know the contents of that block is not yet done syncing.