fix(meade): accept the UTC offset format INDI sends

[rbhbokka]

Regression from #291. INDI cannot set the site's UTC offset, so local time is wrong for every INDI/KStars session.

The defect

The :SG arm of handleMeadeSet() uses Cursor::signed2(), which requires a leading +/- and exactly two digits. INDI sends one digit and a fractional part.

Captured off the wire on an INDI connect to an OpenAstroExplorer:

:SL10:42:31  :SC09/05/26  :SG+7.0  :Sg121*53  :St+37*20

:SG+7.0# is answered 0, the handler never fires, and the offset is silently left unset. The pre-#291 handler ran toInt() over the remainder (inCmd.substring(1, 4).toInt()), which accepted all of these forms.

The fix

A readUtcOffset() helper alongside the other read* helpers, accepting an optional sign and one or two digits, and leaving trailing characters unconsumed so +7.0 parses as +7 — matching the pre-#291 behaviour rather than inventing a new grammar.

Every form that already parsed behaves identically, sign included; +05 → 5 and -08 → −8 on both sides of the change.

Tests

Added under the existing ---- UTC Offset (G) ---- block: the exact INDI form; single-digit positive and negative (the suite never covered that intersection); unsigned; and the +5.5 half-hour case (India, Newfoundland), which truncates because setLocalUtcOffset() takes an int — pinned so the limitation is documented rather than discovered in the field.

One existing test asserted that G+5 was rejected. That was pinning the regression, since the pre-#291 handler accepted it, so it is repointed at genuinely malformed input rather than removed; the rejection path is now covered by two tests instead of one.

pio test -e native: 277 pass (269 on develop + 9 added − 1 repointed). Builds clean for oaeboardv1 and ramps.

Deliberately not included

No range validation. :SG+13 / :SG-15 are accepted on develop today and the tests pin that as-is — adding a -14..+14 check would change behaviour beyond the reported fault and could reject something a real client sends. Happy to fold it in if you'd rather have it here.

Scope is :SG only. :Sg (site longitude) has a related but separate #291 regression with a contested sign convention, so it is not touched here.

File overlap

Touches the same two files as my :Sg change (MeadeParserSet.cpp, MeadeProtocol.hpp), in different blocks. Each is mergeable on its own; whichever lands second will need a trivial rebase and I'm happy to do it.

[ClutchplateDude]

I would contend that this is a INDI defect. The Meade Telescope Serial Command Protocol, Revision 2010.10 from 7 October 2010, is quite explicit that the command is
:SGsHH.H#
A sign and two digit hours, with one decimal.
That said, we should support the 0.5 case as well and since we supported a single digit pre-291, we should probably accept it here too, even if it does not adhere to the LX200 spec.
However, I don't think we should make the sign optional.

[ClutchplateDude]

See comment on main page.

[rbhbokka]

we should support the 0.5 case as well and since we supported a single digit pre-291, we should probably accept it here too [...] However, I don't think we should make the sign optional.

Fair on all three, and I agree it's an INDI deviation rather than a mount defect. I've put that in the :SG docs now, so the next person can see that accepting +7.0 is a compatibility call rather than us following the spec.

The sign is mandatory again. One test flipped; everything else already sent one. I also fixed the header line, which still read :SGsHH#.

One thing I'd rather mention than quietly skip: pre-291 the value went through String::toInt(), which accepts an unsigned number, so :SG07 did work back then. Requiring the sign is a narrowing, not a restoration. I still think it's the right call, since a missing sign is far more likely a client bug than a deliberate +, and guessing wrong puts sidereal time out by double the offset. It's also better than the old behaviour of replying "1" to :SGx having stored 0. I just didn't want to sell it as restoring old behaviour when it isn't.

On 0.5, I'd like to do that as a follow-up PR, because the parser part is the easy half:

• The offset is a single signed byte at UTC_OFFSET_ADDR = 39, in a map packed solid up to 73. There's no spare byte next to it and no unit tag, so reinterpreting it makes an existing mount's stored -5 read as -2:30 with nothing to warn you.
• DayTime::addHours takes a float, so changing the units of an int offset compiles clean and silently doubles the error.
• The lastFlashed migration hook isn't idempotent if someone downgrades and upgrades again. A dedicated ExtendedItemFlag bit would be.
• It also touches the LCD editor and the handler interface.

Three questions, since they're your calls:

1. Are downgrades supported? If not, I'd reuse byte 39 as half-hours behind a new flag bit. If they are, I'd leave 39 as whole hours so old firmware stays roughly right, and append a minutes field.
2. Does :GG stay sHH#? It's been that format forever, and sHH.H# is a 4 to 6 byte reply change that would break fixed-width clients. I can't tell from here whether INDI copes with a decimal.
3. Is :SG+5.3 rejected, or rounded?

Rebased on top of #304.