Anisette resync (hsc 434): init is retried with the fresh client data but the proof request still sends the old cpd #29

What happens

isideload/src/auth/apple_account.rs has a resync path for the "hsc 434" answer (added in #26). It re-sends the initial login request with the freshly resynced anisette data, but the proof request (step 2) is still built with the client provided data taken before the resync.

In 0.4.6 (and current main, same line numbers):

761:        let cpd = anisette_data.get_client_provided_data();     // taken once
768:            .send_init_request(&gs_service_url, &cpd, &a_pub)
...
771:        if let Some(sim) = resync_sim(&raw_response) {
778:            let fresh_cpd = fresh_anisette.get_client_provided_data();
780:                .send_init_request(&gs_service_url, &fresh_cpd, &a_pub)   // init uses fresh data
...
838:                "cpd": cpd, // cpd = client provided data                    // proof still uses the old data

So after a resync, step 1 is retried with the new anisette data (new machine id / one-time password) while step 2 sends the old cpd in the same SRP exchange. The two halves of the login then disagree about which anisette identity is being used — which is exactly the situation this branch exists to recover from, so the resynced login can still be rejected.

Suggested fix

Two lines: make cpd mutable and update it when the resync happens.

-        let cpd = anisette_data.get_client_provided_data();
+        let mut cpd = anisette_data.get_client_provided_data();
@@
             raw_response = self
                 .send_init_request(&gs_service_url, &fresh_cpd, &a_pub)
                 .await
                 .context("Failed to send resynced init request")?;
+            // the proof request below must use the same client data as the resynced init
+            cpd = fresh_cpd;
         }

(fresh_cpd is only borrowed above, so the move is fine; the other cpd uses at 957/967 belong to a different function.)

How I found it

CodeRabbit flagged it on a downstream PR that vendors isideload 0.4.6 (BartolomeoRusso9/altkeeper#8); I checked the code and the finding holds. Reported here because the resync path is what makes 0.4.x work at all after Apple's 2026-10-12 change, so a latent inconsistency in it is worth fixing upstream rather than in every vendored copy.

I have not reproduced it against a live hsc 434 response (that needs Apple to ask for a resync), so this is from reading the code — happy to test a branch if you can tell me how to force that response.