Re-read the account when somebody would notice, and explain the device once

[parawanderer]

Six hours to notice a rename, when an iPad takes seconds

Renaming an AirTag on your own iPad shows up there almost immediately. This app re-read the
account every six hours, so the old name sat on screen for the rest of the afternoon — which
reads as the app being broken rather than patient.

Four ways it updates now, and the difference between them is who asked:

Route	When	A refused sign-in
Settings → read all devices	on demand	→ sign in again (#151)
My Devices → overflow menu	on demand	→ sign in again
On resume	60-second floor	logs, changes nothing
Every 15 minutes while open	was 6 hours	logs, changes nothing

Fifteen minutes is not reckless: the location fetch beside it runs every minute, so four
account reads an hour is not the expensive thing here. The floor on resume exists because
resuming happens on every task switch, and a Python call for flicking between two apps is waste.

The menu item replaces "Link an account" once linking is done — only one of the two is ever what
somebody wants, and offering both reads as three ways in rather than two.

The device-registration page appeared every time

The page explaining what this app put on your Apple account — a row titled after a Mac you do not
own, next to a button offering to remove things you do not recognise, where removing it breaks
your session — was shown on every run of the iCloud flow.

It describes an event. Re-reading a linked account causes none of it, so the page was explaining
something that had not happened, to somebody who read it the first time. A page that turns up
when nothing has happened is one people learn to tap past, including on the run where it matters.

It now shows only when the connection actually registered a device. A fresh install still gets it,
because each one really does add another row.

A design flaw the tests found

AccountRefresher swallowed a refused sign-in into an empty list — so the manual refresh's
onError never fired, and a read that failed looked identical to a successful read of nothing.
The "who asked" decision was sitting inside the one component that cannot know the answer.

It now reports, and each caller decides. Found only because the test drove the menu item rather
than the refresher directly.

Testing

AccountReadPolicyTest moves to the JVM, where arithmetic and three booleans always belonged
(rule 13). That move is also what exposed the gap: adding a parameter to the constructor broke
nothing in the JVM suite, because the only test of the class lived somewhere the JVM suite does
not look.

New: RefreshingFromTheAccountTest (the menu item, including that an outage must not cost a
sign-in) and TheDeviceNoteIsShownOnceTest (shown on a first connection, absent on a re-read, and
the button reads Done rather than Next).

One test hung the suite before it worked: a Toast matched with inRoot(withDecorView(not(...)))
sends Espresso's root picker hunting for a window that is not up yet, retrying for seconds per
attempt inside a retry loop. Killed after ten minutes at three tests of seven. A call count on the
fake answers instantly.

Also

AGENTS.md rule 14 — every call reaching the account has to answer "is this session dead?",
through the shared decision rather than its own, with the who-asked line written down.

Stacked on #151

Branched from fix/a-dead-icloud-session-says-so, because a manual refresh that meets a dead
session needs the classification that PR adds. Merge #151 first.

🤖 Generated with Claude Code