fix: retry GrandSlam auth on 5xx errors and prevent plist format crash

[BananaOnGitHub]

Fixes the recurring "The data couldn't be read because it isn't in the correct format" (NSCocoaErrorDomain code 3840) error encountered during Apple ID login and app refresh operations.

This is currently affecting users in the wild, with recent reports of login/refresh failures:

• [BUG] can't refresh apps after sign in SideStore#1487 — open report of refresh failures persisting for multiple days on a recent SideStore nightly.
• AltServer cannot connect to Apple ID altstoreio/AltStore#1781 — open report of the same NSCocoaErrorDomain 3840 / Encountered unknown tag html on line 1 failure in the upstream AltStore stack.
• Refresh/sign-in fails with NSCocoaErrorDomain 3840; HTTP 503 observed during reproduction altstoreio/AltStore#1782 — open report correlating failed refresh/sign-in attempts with HTTP 503 responses.

A previous detailed SideStore report, SideStore/SideStore#1446, captured the GrandSlam sequence directly: init and complete succeeded with HTTP 200, while the subsequent apptokens request returned an HTML 503 Service Temporarily Unavailable response.

Cause

When communicating with Apple's GrandSlam authentication endpoint (gsa.apple.com/grandslam/GsService2) during init, complete, and apptokens exchanges:

1. Apple's edge servers can return HTTP 5xx responses, including 503 Service Temporarily Unavailable responses with HTML bodies.
2. Previously, sendAuthenticationRequest passed the response directly to PropertyListSerialization.propertyList(from: data, ...).
3. When an HTML error page is parsed as plist data, PropertyListSerialization fails with Cocoa error 3840, producing the misleading user-facing error "The data couldn't be read because it isn't in the correct format."
4. Persistent connection reuse can also cause subsequent attempts to continue hitting the same failing backend/edge connection.

This failure mode has been observed directly in SideStore/SideStore#1446 and is consistent with the currently open 3840 / HTML-response reports above.

Solution

• GrandSlamTransport: Introduced an isolated transport enum specifically for the three GrandSlam auth operations (init, complete, apptokens).
• Connection Isolation: Configures an ephemeral URLSession per attempt (reloadIgnoringLocalCacheData, no URL cache, no cookie/credential storage) to avoid persistent connection pinning to failing edge nodes.
• Exponential Backoff: Retries 5xx responses up to 4 times (delays: 1s, 2s, 4s, 8s). Client errors (4xx) and transport/cancellation errors are not retried.
• Clean Failure Mode: If retries are exhausted, it throws an explicit NSURLErrorBadServerResponse describing the HTTP status instead of passing HTML to the plist parser. Account credentials/bodies are not leaked.
• Unit Tests: Added GrandSlamTransportTests covering successful plist responses, 503 retry recovery, exhausted 5xx errors, non-retried 4xx errors, transport errors, and cancellation during backoff.

Result

For transient GrandSlam 5xx responses, SideSign now retries the request over a fresh connection instead of immediately attempting to parse an HTML error page as a property list.

If Apple's service recovers on a subsequent attempt, authentication continues normally. If the retry budget is exhausted, callers receive a meaningful server-response error rather than the unrelated NSCocoaErrorDomain 3840 plist parsing error.

[mahee96]

this PR is not required, the issue is already resolved.

fyi, URL session doesn't need to be created adhoc like it was done in this PR, and not all network issues need a retry and timeout etc.

If using AI please be responsible to read the code and confirm once that all changes are really addressing the problem (to be specific which problem coz a brute forcing is not a solution) and are performant.

if u try using latest nightly and still face any issues let us know in sidestore's issues.
SideSign is still in development and will be undergoing changes constantly.

[rree9900x-oss]

this PR is not required, the issue is already resolved.

fyi, URL session doesn't need to be created adhoc like it was done in this PR, and not all network issues need a retry and timeout etc.

If using AI please be responsible to read the code and confirm once that all changes are really addressing the problem (to be specific which problem coz a brute forcing is not a solution) and are performant.

if u try using latest nightly and still face any issues let us know in sidestore's issues. SideSign is still in development and will be undergoing changes constantly.

I'm usingvtge latest nightly and I can't refresh my apps