Add time sync source

[yg-ht]

Summary

This is a new feature which will have a corresponding new feature PR sent to the MeshCore project shortly.

It adds authenticated binary time-sync source support for MeshCore repeaters, including broadcast period control and web-UI Packet Stream decoding for time-sync group datagrams.

Changes

• Added authenticated Tv1 time-sync payload generation and signing using the bot/radio identity.

• Sends time-sync broadcasts as MeshCore GRP_DATA datagrams with data_type = 0x0121.

• Added firmware-compatible group datagram send fallback using CMD_SEND_CHANNEL_DATA.

• Persists the time-sync sequence in bot metadata so service restarts do not normally reset to 0.

• Added admin DM commands:

  • timesync status
  • timesync publickey
  • timesync send

• Updated the Real-time monitoring Packet Stream to decode and display time-sync broadcasts.

• Added configuration/docs for [Time_Sync], channel requirements, public key export, sequence persistence, and manual broadcast.

• Added regression tests for command handling, service behaviour, packet decoding, and datagram sending.

[yg-ht]

This is the PR for the Meshcore project:
MeshCore PR 2939

[agessaman]

Status update, since this has been open a while and you deserve to know where it stands rather than watching it sit.

I'm not merging this yet, and it isn't a quality objection — the work is thorough and the packet-stream decoding in the web UI is a nice touch.

The blocker is that time distribution on MeshCore doesn't have a settled answer yet. There's more than one proposal in circulation for clock-tower-style behavior, and if this bot ships one implementation ahead of that, it becomes a de-facto standard by accident — nodes start depending on the Tv1 payload shape and broadcast semantics here, and it gets materially harder to converge on whatever the ecosystem actually agrees to later. A bot is the wrong place to unilaterally set a wire format that repeaters and firmware are expected to interoperate with.

So this stays open, pending consensus on a single approach. Concretely, what would move it: the corresponding MeshCore-side PR landing, or the format otherwise being agreed on rather than proposed. If that happens and this matches, I'm happy to revisit — and if the agreed format differs from what's here, I'd still rather adapt this PR than start over, so the effort isn't wasted either way.

If you have a read on where the upstream discussion currently sits, I'd be glad to hear it — you're closer to it than I am.

Tagging as needing extra attention so it isn't mistaken for a stale PR.