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.

[rbhbokka]

Having a negative flag is my preferred solution as well.

Thanks. That's what's in there now, for all three coordinate types.

I've pushed a second commit, because the first one didn't actually fix the case this PR is named after. The parser was fine, but decFromWire folded the sign flag back into a signed int deg to call fromCelestialDegrees, and zero can't carry a sign. So :Sd-00*30:00 and :Sd+00*30:00 both landed on axis seconds 322200, where the right answer is 325800. One degree out, silently, for anything in the first degree south of the equator.

Latitude and longitude were already fine, they got siteSecondsFrom in the first commit. Declination just never got its equivalent.

Worth knowing why the tests didn't catch it: [env:native] only builds src/core, src/ports and src/adapters, so MeadeCommandProcessor.cpp and src/Declination.cpp are never compiled by pio test -e native. The parser side is covered well, but nothing we have can reach the handler boundary. So the join went into core as core::Declination::celestialSecondsFrom, with a thin Declination::fromCelestialSeconds to consume it. decFromWire is now just those two composed, and the new test pins the old wrong value right next to the new right one.

One correction to my own PR description: I said the other two would rebase trivially on top of this. They don't, sorry. Both conflict in MeadeParserSet.cpp, and this PR rewrites the same case 'G': block to require exactly two digits, which is the thing #303 exists to fix. So merging this alone puts :SG+7.0 back to failing. I've rebased both and stacked them 305 → 304 → 303.