feat: support ERC rotator controllers through the existing GS-232A backend

An ERC (Easy Rotor Control, incl. ERC Mini) emulates Yaesu GS-232A/B, which is
exactly what the backend written for the microHAM ARCO already speaks — azimuth
out (Maaa), azimuth in (C), stop (S), which is the whole of what was asked for.
So this is two small gaps rather than a new backend:

  - Serial speed was hardcoded to 9600. An ARCO's virtual COM ignores it, but an
    ERC runs at whatever its own configuration sets, and a mismatch reads as a
    dead rotator. It is now selectable beside the COM port.
  - The entry was called "microHAM ARCO", so an ERC owner would never have found
    it. It is named after the PROTOCOL now: "GS-232A controller (microHAM ARCO,
    ERC…)".

The help text states the condition plainly in both languages, because it is the
one thing that will otherwise waste an evening: an ERC left on Hy-Gain DCU-1
speaks a different command set and simply will not answer.

Untested on hardware — I have no ERC here, and the GS-232 path itself is proven
on a real ARCO.

internal/rotator/gs232/gs232.go

@@ -1,6 +1,12 @@
 // Package gs232 drives rotator controllers that speak the Yaesu GS-232A
-// protocol, over a raw TCP socket or a serial COM port. The target device is
-// the microHAM ARCO: both its LAN "CONTROL PROTOCOL" setting (a TCP port) and
+// protocol, over a raw TCP socket or a serial COM port.
+//
+// Any controller set to GS-232A works, which is most of them: the microHAM ARCO
+// natively, and the ERC family (Easy Rotor Control — ERC Mini, ERC interface),
+// which EMULATES GS-232A/B over its USB port. An ERC can also be configured for
+// Hy-Gain DCU-1, a different command set entirely, so it must be set to GS-232.
+//
+// On the ARCO: both its LAN "CONTROL PROTOCOL" setting (a TCP port) and
 // its USB port ("USB CONTROL PROTOCOL", a virtual COM where the baud rate is
 // irrelevant) can be set to speak Yaesu GS-232A — so OpsLog controls it
 // directly, no PstRotator in between. ARCO accepts up to four parallel LAN
@@ -37,7 +43,12 @@ const (
 type Client struct {
 	Host    string
 	Port    int
-	ComPort string // serial transport: "COM5" etc. (ARCO USB virtual COM — any baud)
+	ComPort string // serial transport: "COM5" etc.
+	// Baud matters on some controllers. An ARCO's USB virtual COM ignores it, but
+	// an ERC (Easy Rotor Control) runs at whatever rate its own configuration
+	// sets — commonly 9600 or 19200 — and a mismatch reads as a dead rotator.
+	// Zero keeps the historical 9600.
+	Baud int
 }
 
 // New returns a TCP Client with sane defaults applied for empty fields. There
@@ -56,8 +67,8 @@ func New(host string, port int) *Client {
 // NewSerial returns a Client talking over the ARCO's USB virtual COM port. The
 // baud rate is irrelevant on USB per the ARCO manual (8N1 framing matters); we
 // open at 9600 which also suits a real RS-232 hookup left at its default.
-func NewSerial(comPort string) *Client {
-	return &Client{ComPort: comPort}
+func NewSerial(comPort string, baud int) *Client {
+	return &Client{ComPort: comPort, Baud: baud}
 }
 
 // roundTrip opens a connection (TCP or serial per the client's config), sends
@@ -66,9 +77,13 @@ func NewSerial(comPort string) *Client {
 func (c *Client) roundTrip(cmd string, wantReply bool) (string, error) {
 	var conn io.ReadWriteCloser
 	if c.ComPort != "" {
-		sp, err := serial.Open(c.ComPort, &serial.Mode{BaudRate: 9600})
+		baud := c.Baud
+		if baud <= 0 {
+			baud = 9600
+		}
+		sp, err := serial.Open(c.ComPort, &serial.Mode{BaudRate: baud})
 		if err != nil {
-			return "", fmt.Errorf("open ARCO %s: %w", c.ComPort, err)
+			return "", fmt.Errorf("open rotator %s @ %d baud: %w", c.ComPort, baud, err)
 		}
 		_ = sp.SetReadTimeout(200 * time.Millisecond)
 		conn = sp