Measure PPS stability on Time-Pi and TrueTime-Pi

@jclark has an excellent blog post this morning [Measuring systematic PPS bias on the Raspberry Pi 5](https://satpulse.net/2026/09/06/measuring-systematic-pps-bias-on-the-raspberry-pi-5.html), and I'm wondering if he's been reading my mind lately. I was just puzzling over how to verify the *actual* UTC offset (or failing that, comparing PPS output from the GPS module into the Pi kernel), and this is a good solution.

Still has some inherent problems because the Pi doesn't have a mechanism for realtime interrupt handling (especially with RP1 on top now). But I figure we could cut the latency from UTC PPS in half at least. It's only maybe 10-20µs and can be reduced by ensuring nothing is in a low power or DVFS state, but getting it to 1-5µs is better.

Of course, this is one reason the TimeHAT routes PPS right into the NIC's PHY—it can handle the rising edge in hardware and *should* be much more accurate to the nanosecond-level than any GPIO pin could dream of. But even there, I'd like to have more measurable/verifiable stats for all my Pi time server builds, and that post has some nice nuggets.

Start with the linked Raspberry Pi 5 PPS-bias post and inspect how Time-Pi and TrueTime-Pi currently expose GPS and PPS timing. Define measurements comparing UTC PPS with the GPS module's PPS into the Pi kernel, including TimeHAT hardware timing where applicable; done means repeatable stability and latency statistics for the builds.

Written by the indexing model from the issue text.