app: sign in to the server's identity provider

Authorization code with PKCE, a Sign in card in settings, and the echolot://auth
redirect handled next to the enrolment one - told apart by host, because one
spends a token and the other completes an authorization, and confusing them
would fail obscurely.

The detail that decides whether this survives a real phone: the PKCE verifier is
written to storage before the browser opens rather than held in memory. Handing
control to a browser backgrounds the process and Android may kill it, so the
callback arrives at a fresh one. An in-memory verifier works on a developer's
device and fails under memory pressure.

Pending state is cleared before the exchange is attempted, whatever the outcome:
it is single-use, and leaving it behind would let a later callback complete a
flow nobody started.

Also records an open issue the question about server requirements surfaced: two
probes hardcode the reference deployment, so a user with no server still sends
DNS and STUN traffic to fmr without being told. For a tool this careful about
what leaves the device, that is the wrong default.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/build-status.md

@@ -1054,3 +1054,31 @@ Four consequences that decide whether it is worth it:
 What keeps this possible: uploads are already stored byte-for-byte as received, and every index
 field is derived in one function (`runs.Put`). The thing to avoid is admin features that *require*
 reading content — those would have to be unbuilt later.
+
+### App sign-in, and an undisclosed dependency it surfaced (2026-08-01)
+The app can now sign in to the server's identity provider: authorization code with PKCE, a
+`Sign in` card in settings, and the `echolot://auth` redirect handled alongside the enrolment one
+(told apart by host, since one spends a token and the other completes an authorization).
+
+The detail that decides whether this works on a real phone: **the PKCE verifier is written to
+storage before the browser opens**, not held in memory. Handing control to a browser backgrounds
+the process and Android may kill it; the callback then arrives at a fresh process. An in-memory
+verifier works on a developer's device and fails under memory pressure, which is the worst way for
+a sign-in to break.
+
+Nothing from the IdP is retained. The ID token proves who is signing in, once, and the device
+credential authenticates everything after — no access tokens stored, no refresh tokens rotated.
+
+**A server remains entirely optional.** All eight probes are device-tier; `serverConfigured` gates
+only upload and the account. But answering that question exposed something worth fixing: two probes
+hardcode the reference deployment —
+
+```kotlin
+DnsCanaryProbe(canaryZone = "c.echo-lot.app", ...)   // "Hardcoded to the reference deployment"
+StunProbe(serverHost = "fmr-1.echo-lot.app")
+```
+
+so a user with no server of their own still sends DNS and STUN traffic to fmr without being told.
+For a tool that goes to this much trouble over what leaves the device, an undisclosed dependency on
+a third party's infrastructure is the wrong default. It should prefer the configured server, and be
+explicit when there is none. **Open.**