Vacuum full failing xmin check, but vacuum freeze ok on v16

Had an interesting situation recently where a 16.4 database had
experienced some forced vacuuming due to potential wraparound, and a few
days later a vacuum full failed with:

ERROR: found xmin 29,200,398 from before relfrozenxid 284,832,753
(commas are mine :)

Here's the curious part: Both CREATE TABLE AS SELECT and VACUUM FREEZE were
able to run without any problems at all. Nothing else was active on this
cluster (application was shut down to diagnose this). I used
heap_force_freeze to 'fix' the row in question, which made vacfull happy
for that row, but revealed another row right next to it with the same
issue. Examining the row's t_infomask confirmed the row was, indeed, marked
as frozen. Checked another handful of similar rows. All had unique
xmins (i.e. one xmin = one ctid) and xmax always 0, plus sequential primary
key vals, so looked like straightforward inserts. Server has not failed
over, to my knowledge.

So why is vacfull bothering with these rows? What is different about
vacfull vs vacfreeze for this check?

Cheers,
Greg