fix(meade): keep the sign of coordinates whose degrees component is zero

[rbhbokka]

Regression from #291, and a supersede proposal for #241 — see below. Draft, because it changes three public struct shapes and I'd like agreement on the approach before polishing.

The defect

DecCoordinate, MeadeLatitude and MeadeLongitude carry the sign in the sign bit of degrees:

struct DecCoordinate { int16_t degrees; uint8_t minutes; uint8_t seconds; };

That cannot represent a negative value whose degrees component is zero. Cursor::signed2() computes -static_cast<int>(0), which is 0, so the sign is destroyed inside the struct, before any handler can see it:

wire	parsed	stored as
:Sd-00*30:00#	{0, 30, 0}	+00*30:00
:St-00*30#	{0, 30}	+00*30 — equatorial sites
:Sg-000*05#	{0, 5}	+000*05 — central London

A one-degree error in a band straddling the celestial equator, and :CM sync takes the same path, so it lands in the mount's home reference permanently rather than in a single slew.

The pre-#291 DayTime::ParseFromMeade applied the sign to the whole total (sgn * (((degs * 60 + mins) * 60) + secs)) and was correct.

The fix

• Cursor::optionalSign() replaces signed2/signed3. It reports the sign without folding it into a magnitude, which is the primitive whose absence caused the problem — the old helpers bundled "consume a sign" with "consume N digits", and the sign died in the bundling.
• The three structs get an explicit negative field and an unsigned magnitude.
• The readers keep sign and magnitude apart to the end; the writers and the MeadeCommandProcessor boundary read the sign off the undivided total rather than off a divided degrees component.

The accepted grammar is byte-for-byte unchanged. readMandatorySign() preserves the existing requirement for an explicit sign, so this commit changes only what the parser does with a sign it already accepted. A differential fuzz over 176,186 inputs across the whole Set grammar shows the sign-of-zero cases as the only behavioural difference; an exhaustive sweep of the Get writers is byte-identical to develop.

On #241

#241 diagnosed this exact root cause in 2024 and proposed the right remedy — carry the sign as its own channel instead of in the sign bit of a magnitude. Its two target functions, Longitude::formatString() and Longitude::formatStringForMeade(), have had no callers since #291 routed around them, so it no longer changes behaviour. This applies the same idea where the code now lives. Credit to @peteasa for the diagnosis; happy for this to be closed in favour of a reworked #241 if that's preferred.

Approach — the thing I'd like ruled on

I took the smaller of two options: an explicit negative field. The alternative is replacing the components with a single signed total (int32_t arcseconds / arcminutes) plus fromDms/toDms, which makes the hole impossible rather than merely fixed and collapses several call sites — but it is a much larger diff against structs that #296 and #299 are currently contesting.

If you'd rather have the signed-total version, say so and I'll redo it that way. The redundant state in the current shape (a magnitude that can't be negative, plus a flag) is a fair criticism and I'd rather resolve it before this is polished than after.

Verification

pio test -e native: 298 pass (269 on develop + 29 added, none removed). Builds clean under -Werror for oaeboardv1 (ESP32) and ramps (AVR, 16-bit int — relevant since the struct layout changed).

Not fixed here

Declination::fromCelestialDegrees() has a separate sign bug of its own, fixed in #302. The two are complementary: #302 makes the join move the magnitude away from zero, this one makes sure a sign exists to move it in.

File overlap

Rewrites the three readers that #304 (:Sg) modifies, and touches MeadeParserSet.cpp in common with #303. Independently mergeable; I'll rebase whichever lands later.

[ClutchplateDude]

Having a negative flag is my preferred solution as well.