That settles it, thanks for running it. 0.3s against 16s on the same VM is a cleaner answer than I expected.
I read the commit Teddy linked, and it makes your "same thing or two things" question look like one thing: f24df84cbe05 registers the jiffies clocksource before it gets used, because until then its max delta sits at zero and reads clamp to zero, so time stops advancing. If that's the right read, console=ttyS0 isn't a second bug, it's just more wall clock spent inside the window where the clock is stuck.
Take it with a grain of salt, that's me reading a commit message rather than testing anything, so don't take it from me.
More useful, maybe: I went and checked kernel/time/jiffies.c across the stable branches, and the fix is in 6.12.97+, the current 6.18.y, 7.1.4+ and 7.2, but not in 7.0.y, which isn't on kernel.org's maintained list any more. So on your 7.0.0-29 it looks like it has to come from Canonical rather than from an upstream stable update.
Nothing in the patch is CPU-vendor specific either, for what that's worth.
