fix: repair the SMS 2FA flow (active 412 challenge and -22979/-22981 throttling)

[BK0STAR]

Problem

The SMS 2FA flow fails (reported in nab138/iloader#319): send_sms_2fa treats every non-2xx response without serviceErrors as fatal. Two cases were mishandled:

1. HTTP 412 with an active SMS challenge — Apple returns a valid challenge (mode: sms, trusted number, no lockout flags), but the request aborted instead of moving on to code entry.
2. Throttling -22979 / -22981 ("Too many verification codes…") — routed to NeedsUnknown2FA, which loses the selected phone number and forbids SubmitCode/ResendCode. Yet -22979 explicitly says "Enter the last code you received": a code was already sent and stays valid.

In addition, the phone number ID was hardcoded to 1 instead of loading the trusted phone numbers.

Fix

• Strict 412 classification (classify_sms_send_response): checks mode, authenticationType: hsa2, matching phone-number id, code length 6, and no lockout flags → SmsSendOutcome::ActiveChallenge (proceeds to verification).
• -22979 / -22981 → NeedsSMS2FAVerification(id) with last_error, keeping the selected number and without triggering another send.
• -28248 → kept as NeedsUnknown2FA (choose another method).
• Load the trusted phone numbers instead of the hardcoded 1.

Tests

• Added sms_send_response_tests (10 contract tests: active challenge, wrong number, malformed response, lockout flags, preserved service errors).
• Added cargo test -p isideload to CI.
• cargo test -p isideload: 10/10 passing.

Real-world verification

Tested end-to-end with iloader (v2.3.1 + this isideload): at -22979, the UI shows the code-entry field with the selected number kept; a code generated from a trusted device completes the login. ✅

Fixes nab138/iloader#319

[Copilot]

Pull request overview

This PR fixes edge cases in the Apple SMS 2FA flow by correctly handling “active SMS challenge” (HTTP 412) and SMS throttling service errors (-22979/-22981), while avoiding a hard-coded trusted phone number ID by requiring selection from the retrieved trusted numbers.

Changes:

• Add strict classification for SMS send responses to treat HTTP 412 as an already-active SMS challenge when the response matches expected hsa2 + selected number + unlocked 6-digit code constraints.
• Preserve and route throttling service errors -22979 / -22981 to SMS code entry (NeedsSMS2FAVerification(id)) without losing the selected number or triggering a resend.
• Add contract-style unit tests for SMS send response classification and run cargo test -p isideload in CI.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
isideload/src/auth/apple_account.rs	Improves SMS 2FA send error handling/classification, preserves selected phone number across throttling, adds tests, and removes hard-coded trusted number selection.
.github/workflows/build.yml	Adds CI coverage for isideload tests to catch regressions in the auth flow.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[nfrhnh]

Tested this end-to-end on Linux and can confirm it fixes the 412 SMS 2FA failure.

Setup: built iloader v2.3.1 from source with isideload pointed at this branch (commit f560857), together with the matching frontend changes from nab138/iloader#607.

Account state: Apple ID with SMS 2FA whose trusted phone number is flagged non-FTEU ("phoneNumber": {"nonFTEU": false}). Apple sends the SMS immediately during the GET /auth challenge step, and the subsequent PUT /auth/verify/phone returns 412 with all securityCode flags false.

Before: iloader surfaced "SMS 2FA code submission failed with http status 412 Precondition Failed" and never showed the code input.

After: the 412 is classified as an active challenge, the app proceeds straight to the SMS code entry screen, and submitting the code that arrived on the phone completes the login successfully.

Caveat found during testing: for accounts where the previous 2FA attempt was marked failed, the flow lands in the NeedsUnknown2FA branch, which requires the frontend to ask the user which method/number to use (2fa-required / 2fa-response events). That UI only exists in nab138/iloader#607, so I'd recommend reviewing/merging the two together — with only this backend change, iloader's current frontend still fails with "Cannot submit code without knowing which method to use" for those accounts.

[BK0STAR]

Thanks for the thorough end-to-end testing @nfrhnh! Great to hear it resolves the 412 SMS 2FA flow.

Your caveat about NeedsUnknown2FA is spot on — the frontend changes in nab138/iloader#607 are specifically designed to handle that branch (method/number picker, resend, send-to-devices). The two PRs are intentionally structured to be merged together, as you've confirmed through your own testing.

For maintainers (@nab138): once isideload#9 is merged, I can immediately update Cargo.toml in iloader#607 to pin the new commit, regenerate Cargo.lock, and mark it ready for review.

[nab138]

See my comment in nab138/iloader#607