fix(spid): a Rot1Prog takes three digits, so every target went the wrong way

Field report from a tower: on a RAK/RAU in Rot1Prog, every commanded heading
made the antenna want to turn nearly a full circle ANTICLOCKWISE — 0°, 90°, any
of them — while the heading readout, the stop button and everything else worked.

BuildSet framed the four-digit Rot2Prog azimuth for both dialects. A Rot1Prog
reads three: its replies are three digits in a five-byte frame, and its command
field matches. So 90° went out as "0450" and was read as 045 — 45 − 360 = −315°.
Every target landed 360° low, which is why it was always anticlockwise and
always nearly a full turn. The operator's own guess, that OpsLog was in 720°
mode, was the right instinct in the wrong place: the fault is a decimal shift,
not a range.

The round-trip test added here is the one that would have caught it without a
tower — every degree of the circle through the command builder and back through
the reply parser, which must return the degree that went in. The frame tests
pinned the Rot2Prog form against the reference and said nothing about the other
dialect.

Two more from the same report. A rotator test that only READS the heading — SPID,
ARCO, DCU-1 — said "Packet sent, the antenna should swing to north, check
PstRotator's UDP listener", naming a program not in the path for a move never
commanded; it now says the controller answered and nothing was moved. And the
compass polled every three seconds, so a turning antenna moved the needle in
steps of about thirteen degrees; the heading now has its own 700 ms tick while
the relay boards and the antenna controller stay at three seconds.

internal/rotator/spid/spid.go

@@ -6,7 +6,7 @@
 // just to turn an antenna. Two towers with a controller each is the ordinary
 // case; each one is a separate serial port and a separate rotor in OpsLog.
 //
-// WIRE FORMAT
+// # WIRE FORMAT
 //
 // Every command is 13 bytes:
 //
@@ -30,6 +30,13 @@
 //
 //	az = H1×100 + H2×10 + H3 + H4/10 − 360
 //
+// ROT1PROG IS THREE DIGITS IN BOTH DIRECTIONS. Its reply carries three, and so
+// does its command — the controller reads the azimuth from offsets 1, 2 and 3,
+// with no resolution scaling (it is one pulse per degree). Sending it the
+// four-digit Rot2Prog form shifts every target by a decimal place: 90° goes out
+// as "0450" and is read as 045, which is −315°, so every command turns the
+// antenna nearly a full circle the wrong way. Found on a tower, not here.
+//
 // The 360 offset is what lets the controller report a rotator that has turned
 // past north in either direction, which is the point of a pulse-counting
 // rotator: −180…540 rather than 0…359.
@@ -111,7 +118,22 @@ func BuildStop() []byte { return buildCmd(0, 0, 0, 0, cmdStop) }
 // Azimuth is offset by 360 before scaling, so a target of −10° and one of 350°
 // are different instructions: the first turns anticlockwise past north, the
 // second does not. Feeding a 0…359 heading in is therefore always safe.
-func BuildSet(az, el float64, resolution byte) []byte {
+//
+// ROT1PROG SENDS THREE DIGITS, NOT FOUR, and that is the whole reason this
+// takes a model. Its reply is three digits — a 5-byte frame — and its command
+// field matches: the controller reads the azimuth from offsets 1, 2 and 3.
+//
+// Sending the four-digit Rot2Prog form to one shifts every target by a decimal
+// place. "0450" for 90° was read as 045, i.e. 45 − 360 = −315°, so every
+// command became a near-full turn ANTICLOCKWISE whatever was asked for — 0°,
+// 90°, 180°, all of them. That is exactly how it was reported from a tower:
+// every heading wanted to go the wrong way round, and a "point to 0°" test that
+// did nothing useful.
+func BuildSet(az, el float64, resolution byte, model Model) []byte {
+	if model == Rot1Prog {
+		// No scaling: a Rot1Prog is one pulse per degree and reports resolution 1.
+		return buildCmd3(int(360+az+0.5), int(360+el+0.5))
+	}
 	if resolution == 0 {
 		resolution = 1
 	}
@@ -120,6 +142,26 @@ func BuildSet(az, el float64, resolution byte) []byte {
 	return buildCmd(uaz, uel, resolution, resolution, cmdSet)
 }
 
+// buildCmd3 frames a Rot1Prog target: three ASCII digits per axis at the same
+// offsets its replies use, the fourth digit position left as '0'.
+func buildCmd3(uaz, uel int) []byte {
+	c := make([]byte, 13)
+	c[0] = frameStart
+	c[1] = '0' + byte(uaz/100%10)
+	c[2] = '0' + byte(uaz/10%10)
+	c[3] = '0' + byte(uaz%10)
+	c[4] = '0'
+	c[5] = 0x01
+	c[6] = '0' + byte(uel/100%10)
+	c[7] = '0' + byte(uel/10%10)
+	c[8] = '0' + byte(uel%10)
+	c[9] = '0'
+	c[10] = 0x01
+	c[11] = cmdSet
+	c[12] = frameEnd
+	return c
+}
+
 func buildCmd(uaz, uel int, ph, pv byte, k byte) []byte {
 	c := make([]byte, 13)
 	c[0] = frameStart
@@ -175,7 +217,7 @@ func (c *Client) GoTo(az int, el int) error {
 	if el >= 0 && c.model == Rot2Prog {
 		e = float64(el)
 	}
-	_, err := c.exchange(BuildSet(float64(az), e, res), 0)
+	_, err := c.exchange(BuildSet(float64(az), e, res, c.model), 0)
 	return err
 }