Send GuidanceLineSwathWidth (DDI 512) to implements

[gunicsba]

Problem

DDI 512 (GuidanceLineSwathWidth, "the distance between two adjacent guidance lines in a guidance pattern") is not sent to implements today. The tramline branch (#73) sent a hardcoded 6000 mm (// 6000mm for ESPRO; TODO: derive from DDOP geometry), which is wrong for any other implement, so #84 (guidance track data) deliberately leaves it out. Implements that use it for tramline calculations have no swath width from us.

Where the value should come from

Swath width is the spacing between adjacent guidance lines, which is AgOpenGPS's own concept, so the source should be AgOpenGPS rather than something guessed from the implement. It can also differ from the implement's own working width (a tramline pattern can be spaced for a different, wider machine).

AOG currently doesn't send it: the PGN 0xF4 payload (see docs/PROTOCOL.md §2.5) carries only the sequence, flags, reference line ID and the current/left/right track numbers. So this needs an AOG-side change first (an extra field on 0xF4 or a separate PGN) — worth checking what AOG already exposes before designing it. AgOpenGPS#1218 is the AOG side of the tram work linked from #73.

Why not derive it from the DDOP

Working width detection from the DDOP is unreliable today (#21): implements that report their geometry as Device Process Data rather than static Device Properties have 0 in the DDOP, and the values only arrive once the implement reports them. The tramline branch had a fallback that used the live-reported working width (ClientState::try_get_reported_working_width; it is in the backup/tramline-pre-split-20260919 tag) and it was left out of the split PRs. That may still be useful as a fallback, or for other consumers of the implement width, but it isn't a substitute for the guidance line spacing.

To do

• Decide the source with the AOG side, and add the field/PGN there. Document it in docs/PROTOCOL.md §2.5.
• Parse it in the UDP handler (with a unit test for the parser) and keep the last value.
• Send DDI 512 from MyTCServer::send_guidance_track_data while a track is valid, and skip it when the value is 0 or unknown. Add DDI 512 to is_guidance_data_ddi in task_controller.cpp so it gets mapped.
• Decide what to do when AOG doesn't provide it (older AOG): send nothing rather than a guess.
• Check on hardware with an implement that consumes DDI 512.
• Update docs/PROTOCOL.md §5.4.1 and the readme's guidance list.

Related: #73, #84, #21.

[gunicsba]

The TC side is now in #84: it reads an optional swath width (uint16 LE mm, bytes 10-11) from PGN 0xF4 and sends DDI 512 while a track is valid, skipping it when AOG omits the field or reports 0. The AOG side is AgOpenGPS-Official/AgOpenGPS#1218, which sends AOG's track spacing (tool width minus overlap) in those bytes. What remains here is hardware testing with an implement that consumes DDI 512; the issue can close once #84 merges and that is confirmed.