[lazzurs]

Fixes #126.

Problem

Every call into Python held PythonLock, because FindMy.py's sync AppleAccount enters its event loop per call with run_until_complete. A first import walks thousands of key indices inside a single fetch_location, so opening the iCloud screen during one meant waiting minutes.

Change

• app/src/main/python/account_loop.py (new): attach(account) replaces _evt_loop with a stand-in that submits coroutines to the real loop, which runs forever on its own thread. Same loop, session and identity.
• The account is still used by one operation at a time. request_pet (called when a keychain session opens) swaps the login state across a GSA round trip, so a report request running beside it would read a missing dsid. Ordinary calls hold the account's turn for their whole length; location fetches run inside interleaving() and take the turn once per fetch_raw_reports. An iCloud step therefore waits for at most one request.
• main.py attaches on sign-in and restore, detaches in closeAccount, and wraps the two fetch call sites in interleaving(). An account dropped without being closed stops its thread via a finaliser.
• attach degrades rather than raising: if the pinned FindMy.py ever stops exposing fetch_raw_reports or _evt_loop, the account still gets its thread (fetches then take whole turns) or is left as it was.
• icloud_bridge.openSession refuses an account whose loop is not attached. The iCloud test double and OpeningARealICloudSessionTest attach their accounts.
• PythonICloudService and FetchFromICloudActivity no longer take PythonLock. Location fetches still take it against each other.
• Removed icloud_loading_waiting_for_location_check from all locales with scripts/add_strings.py --remove; that wait no longer exists.
• AGENTS.md rule 21 documents the constraint.

Testing

• test_account_loop.py: 17 tests against the real pinned AppleAccount with only the network replaced. They cover an iCloud call completing mid-walk, no overlap with an in-flight request, the reentrant turn, closing with calls queued, abandoned accounts, where main.py attaches, and the degraded paths. Each core assertion was confirmed to fail with the corresponding part removed.
• Python suite: 332 passed. pyright 1.1.411 and flake8 clean. add_strings.py --check passes.
• Gradle testDebugUnitTest: 471 JVM tests, 0 failures. Static checks, build and the emulator suite are green on the fork: Run the account's loop on its own thread so iCloud calls stop queueing behind fetches lazzurs/OpenTagViewer#1
• Not verified: a real Apple sign-in and location fetch on a device. One sign-in attempt on a phone with this build failed. That matches App: Can't log in #248 (Grand Slam refusing every install since 12 October, fix in Sign in as the Android device the ADI libraries actually are — fixes #248 #261), but I have not confirmed that was the cause. The open question specific to this change is Chaquopy calling Java (local Anisette otp()/machine()) from the loop thread rather than an Rx thread. The branch merges cleanly with Sign in as the Android device the ADI libraries actually are — fixes #248 #261, so it can be re-tested on top of it.

🤖 Generated with Claude Code