Sanitize X-MMe-Client-Info to avoid Apple's Xcode-based GSA block

[Rogue911]

Problem

Since ~early September 2026, every Apple ID sign-in through this project fails
with an HTTP 503 from gsa.apple.com/grandslam/GsService2, before Apple's
authentication logic is ever reached.

Root cause

Credit for the actual root cause goes to
altstoreio/AltStore#1790:
Apple's GSA edge rejects any request whose X-MMe-Client-Info header
contains the substring com.apple.dt.Xcode, independent of version,
User-Agent, or connection reuse. That PR fixed it for AltStore's own (Swift,
macOS) anisette code.

This project doesn't share that code — it fetches anisette data as JSON from
an external anisette server (AnisetteDataManager::FetchAnisetteData), and
the X-MMe-Client-Info value such servers commonly return still identifies
as Xcode, tripping the same block. I confirmed this independently with two
otherwise-identical requests directly against the live endpoint:

X-MMe-Client-Info containing "com.apple.dt.Xcode" -> 503 (blocked at the edge)
X-MMe-Client-Info containing "com.apple.akd"      -> 401 (reaches the real service)

Fix

Adds a small SanitizeClientInfo() helper in AnisetteDataManager.cpp that
rewrites that one substring at the single point anisette data enters this
program (right when the anisette server's JSON response is parsed), so every
downstream call site in AltSign that later forwards
anisetteData->deviceDescription() as the X-MMe-Client-Info header (there
are four of them) is covered without needing to touch vendored AltSign code
at all.

This is intentionally scoped to just this one issue. It does not include
the separate, already-known GrandSlam "reuse the same connection for 3
requests" fix (AltSign#52 /
#47), since that lives in
the vendored AltSign submodule rather than this project's own code, and
would need a different approach (e.g. extending
rewrite_altsign_source.py) to contribute cleanly. Happy to follow up with
that separately if useful.

Testing

Verified end-to-end against a real iPhone and a real Apple ID over several
days of testing (no device or account details included here). Before this
change, GrandSlam requests failed with HTTP 503 on the very first request.
After it, requests reach Apple's authentication service normally (structured
200/401 responses instead of an opaque 503 HTML page), and a full
sign-in + IPA install completes successfully.

Not tested on 32-bit ARM/x86 builds, only x86_64.

[Rogue911]

Closing to recreate this PR from a clean branch (accidentally included an unrelated internal link in the first push). Will open a fresh PR shortly.