Re-authentication reported success for work it never did. The branch
took appPassword and dropped `found` and `selected` on the floor, so a
user whose account had 401'd walked the whole add flow, ticked
collections, and was shown Done — while no newly-ticked list was
created, and a moved principal or corrected username was discarded, so a
relocated account could never be repaired. It also never called
accounts.add, so an account deleted in Android Settings (nothing listens
for LOGIN_ACCOUNTS_CHANGED) stayed absent from Settings for ever while
syncing happily via WorkManager, and every later add answered
AlreadyExists. Unticked lists are still left attached, deliberately: the
picker pre-ticks what is *writable*, not what this account already
holds, so detaching would stop syncing a read-only share over a default
nobody chose.
Remove-then-re-add duplicated every list. remove() leaves them behind as
device-only lists on purpose and create() always inserted, so the user
got their old Personal full of tasks beside a freshly synced Personal
holding the same tasks from the server — the outcome the comment next to
it names as the one to avoid. A collection whose href is already on the
device is re-attached now, keeping its name, colour, ordering and tasks
and losing only a cursor that belonged to the account that is gone.
Rollback follows: it deletes what this attempt created and lets the FK
return a re-attached list to being device-only.
An account in the system with no Room row could not be removed from
inside the app — accounts.remove's result is ignored and find returns
null while the device is locked, so the pair can come apart, and every
later add then answered AlreadyExists with the accounts screen driven
off Room. That state is treated as an orphan to clean up.
create()'s tail is uncancellable, like remove()'s: a back gesture during
"Adding the account" left the row and its lists with no credential and
no system account, where the rollback never runs, needsSignIn is false
so re-auth will not fire, and every retry answers AlreadyExists.
remove() forgets the quarantine counts as well as the cadence cursors —
same keys, same globality, and a list re-attached to a new account would
otherwise inherit a resource that is skipped for ever.
And NeedsAuthentication's doc claimed the caller widens a credential
allowlist with its hosts. Nothing does, and nothing should without the
user's say-so; it says what the list is actually for.