2FA loop: Apple no longer honors the Xcode 11.2 client identity (`com.apple.dt.Xcode/3594.4.19`)

Sign-in gets stuck in a loop that looks like a 2FA bug. Apple accepts the verification code
(HTTP 200), but the next SRP login is challenged again with hsc=409 / au=secondaryAuth, so
re-entering codes never helps. Same symptom as #1737 and SideStore#1247.

Cause

X-MMe-Client-Info describes Xcode 11.2 (2019) on macOS 13.1. Apple appears to validate that the
triple is internally consistent before granting HSA2 trust, and Xcode 11.2 / a current Xcode on
macOS 13.1 is not a combination that can exist.

Measured on macOS 27 with the PR #1770 anisette VM:

The stale value reaches Apple because anisette sources report it and
ALTAnisetteData(anisetteServerResponse:) copies X-MMe-Client-Info verbatim:

• PR #1770's Linux VM reports <MacBookPro13,2> <macOS;13.1;22C65> … 3594.4.19>
• All five servers in anisette-servers.json report the same string (checked via /v3/client_info)

Fix

One file. AnisetteDataManager.swift:249 already derives the model, OS version, and build from
ProcessInfo for the AOSKit path. Using that same derived string for the VM/anisette-server path,
with the Xcode version bumped, is sufficient:

<Mac17,3> <macOS;27.0;26A5416b> <com.apple.AuthKit/1 (com.apple.dt.Xcode/25183.54.10)>

Only the Xcode version is pinned; model and OS come from the machine.

Notes

• No AltSign change is needed. Verified with AltSign stock — X-Xcode-Version: 11.2 (11B41)
  and User-Agent: akd/1.0 CFNetwork/978.0.7 Darwin/18.7.0 unchanged. Stale, but not
  load-bearing.
• The SMS fallback is a symptom, not a separate bug. On a fresh, untrusted machine (deleted
  adi.pb/identifier, let the guest re-provision), a coherent identity made Apple return
  trustedDeviceSecondaryAuth instead of secondaryAuth. The existing
  requestTrustedDeviceTwoFactorCode path handled it unmodified and the retry returned 200.
• iOS needs a different form of the same fix. FetchAnisetteDataOperation on classic also
  takes the server's client info verbatim, but has no local Mac to derive from, so it would need a
  pinned coherent triple. iSideload does this (isideload/src/anisette/remote_v3/mod.rs).
• Confirmed on AltServer (macOS 27) and AltStore Classic 2.3b2 with a remote anisette server.
• Tested with a sign-in-only harness — no device, certificates, or install — so each field could
  be varied independently.

Happy to open a PR against marketplace if this looks like the right approach.

Investigated with Claude Code.

Start at AnisetteDataManager.swift:249, where the AOSKit path derives the model, OS version, and build, and compare it with the VM/anisette-server path. Ensure the resulting client identity is coherent while preserving the locally derived model and OS values, then use the sign-in-only harness to confirm the retry succeeds without another secondaryAuth challenge.