Port the Authress login SDK; rework the theme picker and onboarding

[wparad]

Authentication

The app treated Authress as a plain OAuth provider and drove it through AppAuth against /authorize and /oauth/token. Neither path exists — both came from b3f6eff, the commit that invented the Numaeel product and its domains.

Authress is not an OAuth provider in that shape, so correcting the URLs would not have helped either. @authress/login-react-native is now ported directly:

POST /api/authentication          -> authenticationUrl + authenticationRequestId
open authenticationUrl in the browser
redirect to ch.rhosys.email://auth/callback  -> code + authenticationRequestId
POST /api/authentication/{id}/tokens         -> session cookies

The session is held in the authorization and user cookies, not an access/refresh pair.

Ported file by file:

File	From
JwtManager	jwtManager.ts — PKCE S256, payload decode, the 10s exp skew buffer
AuthStorageManager	authStorageManager.ts — pending PKCE state in encrypted storage
AuthressCookieJar	authStorageManager.ts — live jar plus encrypted mirror, with backupCookies / restoreCookies at the SDK's own call sites
AuthressLoginClient	loginClient.ts — the flow, getToken, waitForToken, userIsLoggedIn, logout

Session upkeep uses the SDK's own methods rather than an invented mechanism: userIsLoggedIn() refreshes via PATCH /session and is called on every route change, as its documentation recommends, and waitForToken() supplies the Authorization header so a request issued mid-refresh waits rather than being rejected.

AppAuth is replaced by androidx.browser. The hosted page opens in a Custom Tab — the real browser, so passkeys and the password manager work. The browser does not share cookies with the app and does not need to: the token exchange is made by the app's own HTTP client, so the session cookie lands there.

This also resolves the duplicate redirect claim. AppAuth's RedirectUriReceiverActivity no longer competes with MainActivity for the scheme, and MainActivity forwards the redirect through onNewIntent as the SDK's Android setup describes.

The application id now defaults to app_2EAWGEdtzaeCj7b45DsDtt, matching the web app's VITE_AUTHRESS_APPLICATION_ID.

Theme picker

Five FilterChips all drew from the active theme, so every option rendered identically and none previewed what selecting it would do.

Each option is now a 168dp tile painted from its own palette — base as the ground, mantle for the footer, the text/subtext ramp, the seven accents, and two miniature mail rows. The two rows are what distinguishes the dark flavours from each other, which a flat swatch would not show. System splits between the two palettes it resolves to.

Selecting a flavour now sets it outright; previously tapping the selected chip reverted to system, which was undiscoverable and is redundant now that System is a tile.

Used by both Settings and onboarding's "Pick a look" step, which had the same problem.

Onboarding

Drops the biometric-lock step — a security preference belongs in Settings, not in the way of a first launch. Four steps instead of five.

Verification

compileDebugKotlin, lintDebug and testDebugUnitTest pass locally and in CI. No warnings.

Not verified: nothing has run against a live backend, and no test covers the new auth code. The parts to watch on first real login are the PKCE encoding, the iss comparison against https://login.rhosys.cloud, and the deep-link parsing.