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.

Fix

• Strict 412 classification (classify_sms_send_response): checks the SMS/HSA2 challenge, matching phone-number ID, six-digit code configuration, and lockout flags before proceeding to verification.
• -22979 / -22981 → NeedsSMS2FAVerification(id) with last_error, keeping the selected number without triggering another send.
• -28248 → NeedsUnknown2FA, allowing the caller to choose another method.
• Preserve the existing secondaryAuth fast path by attempting SMS first; the callback still exposes trusted-device and method-selection fallbacks when needed.

Verification

• cargo build -p minimal: OK.
• cargo test -p isideload: OK.
• rustfmt --check isideload/src/auth/apple_account.rs: OK.
• Tested end to end with iloader: at -22979, the UI keeps the selected number and displays the code-entry field; a trusted-device verification code completes login.
• Independently tested end to end on Linux by @nfrhnh with the matching frontend changes from fix: complete the 2FA flow (method and number picker, error recovery) iloader#607.

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

[nab138]

Thank you for the PR! I left a few comments but other than that this looks good. Once those are resolved I will merge!