fix: handle Apple's new trustedPhoneNumbers location in auth response

[matzekl]

Summary

• Apple moved trustedPhoneNumbers from twoSV.phoneNumberVerification to twoSV.bridgeInitiateData.phoneNumberVerification in the HTML response from https://idmsa.apple.com/appleauth/auth
• This causes get_trusted_phone_numbers() to return an empty list, hiding the SMS 2FA option entirely
• Combined with iOS 26 removing the manual "Get Verification Code" button from Settings, users have no way to authenticate
• The fix checks both the original and new location, falling back to bridgeInitiateData when the original path is empty

Fixes #1322

How I found this

Captured the actual Apple auth response and compared the JSON structure to what the parser expects:

# What the parser looks for (old):
twoSV.phoneNumberVerification.trustedPhoneNumbers → []  (empty)

# Where Apple now puts it (new):
twoSV.bridgeInitiateData.phoneNumberVerification.trustedPhoneNumbers → [{id: 1, ...}]

Test plan

• Verified the parser returns 0 devices with the unpatched code against a live Apple auth response
• Verified the parser returns the correct trusted phone number after the fix
• Built a patched Docker image and confirmed the SMS option (a: (***) ***-**88) now appears in the 2FA prompt
• Backwards compatible: still checks the original location first

🤖 Generated with Claude Code

[dotnjet]

I run it with two accounts. One is connected to an iPhone with iOS 26.3 and the 2nd one with iOS 26.4.
It is the update to iOS 26.4 causing it.

[naszta]

Nice, can we merge it?