sync(chunk 2d): the account-add flow

One flow, one back-stack entry, as a stepper rather than four destinations —
the steps are not independently reachable, and "back" from the browser step
abandons a server-side flow rather than popping a screen. It hangs off Settings
with the same sliding-section pattern Storage -> Export uses.

address -> discovery -> (Nextcloud browser approval | username + password)
        -> pick lists -> add account

Provider warnings come before the attempt, not after: type a Fastmail or iCloud
address and the app password rule is stated while you type, which is the single
most common support ticket a CalDAV client inherits. Google is refused with the
reason. A login-flow host mismatch is shown, not refused — reverse proxies are
ordinary on self-hosted installs.

PreemptiveBasicInterceptor is deleted. The vendored BasicDigestAuthHandler
already sends Basic preemptively over HTTPS, also does Digest (Baikal defaults
to it, OkHttp has none), caches the working scheme, and scopes by registrable
domain — which is what iCloud's cross-host home set needs. Two implementations
of one job is the defect chunk 1 removed from ICalendarWriter.

⚠️ That handler compares its `domain` against the *registrable* domain, so
passing the full host meant credentials were withheld from every request to
every subdomain — i.e. every self-hosted Nextcloud, silently 401ing forever.
Pinned by CalDavHttpTest.

CalDavGateway and AccountCreator put the network and the database behind
interfaces so the sign-in state machine is testable without a server, a
database, a Keystore or an AccountManager. It had no tests, and the review
found eight issues in it.

Account creation is transactional and rolls its lists back explicitly:
account_id is ON DELETE SET NULL, so deleting the row alone leaves orphan
lists behind and every retry adds another set.

docs/SYNC-PLAN.md

@@ -277,6 +277,40 @@ before chunk 2 is done.
 
 ## Chunk 2d — the account-add UI
 
+One flow, one back-stack entry, as a stepper rather than four destinations — the
+steps are not independently reachable, and "back" from the browser step means
+abandoning a server-side flow rather than popping a screen. It hangs off Settings
+using the same sliding-section pattern Storage → Export already uses.
+
+⚠️ **`PreemptiveBasicInterceptor` was deleted here**, not kept. The vendored
+`BasicDigestAuthHandler` already sends Basic preemptively over HTTPS, and it also
+does Digest (Baïkal defaults to it and OkHttp has none), caches which scheme
+worked, and restricts by *registrable domain* rather than exact host — which is
+what a cross-host home set needs, since iCloud puts the principal on
+`caldav.icloud.com` and the home set on `pNN-caldav.icloud.com`. Shipping two
+implementations of preemptive Basic is the same defect chunk 1 removed when
+`ICalendarWriter` stopped carrying its own folding.
+
+**A seam was added for testability, after the review found eight issues in one
+untested ViewModel.** `CalDavGateway` and `AccountCreator` put the network and
+the database behind interfaces, so the sign-in state machine — which decides
+where five discovery outcomes lead, when a one-shot app password is spent, and
+which host a credential is scoped to — is exercised without a server, a
+database, a Keystore or an `AccountManager`.
+
+**Still open, and small:** the system entry point (Settings → Accounts → Add
+account → Agendula) refuses with a message pointing at the in-app flow rather
+than driving it. Wiring it means `MainActivity` handling
+`SyncAuthenticator.ACTION_ADD_ACCOUNT` and answering the
+`AccountAuthenticatorResponse`.
+
+**Done when:** the flow has had an on-device review and an explicit go-ahead —
+`CLAUDE.md`'s rule, and this is the case it exists for.
+
+---
+
+## Chunk 2d — the account-add UI (original outline)
+
 **Goal:** the app can add a CalDAV account and list its VTODO collections. No
 syncing yet.