fix(android): retain HTTPS sessions with upstream default cookie flags

Reproduce browser-success/native-401 with unmodified upstream SESSION_SECURE=false behind HTTPS. Keep cookies in the existing HTTPS-only origin-bound encrypted jar regardless of the server Secure attribute; preserve TLS, redirect, expiry and origin protections. Distinguish credential/2FA rejection from missing/rejected session handoff and clear stale login errors on retry. Verify 13 JVM tests plus the 7-test real-server suite in both Secure/default-cookie modes, including bad-password then successful native login. Bump Android preview to 0.2.1/code 3; extend CI and document the defect without claiming access to the user's production server.

docs/login-troubleshooting.md

@@ -0,0 +1,51 @@
+# Android native login: 0.2.1 preview fix
+
+## Reproduced compatibility defect
+
+The Android 0.2.0 native preview could show “Anmeldung oder Sitzung ist nicht mehr
+gültig” even when the identical direct username/password login worked in the PWA.
+Upstream defaults to `SESSION_SECURE=false`; an HTTPS reverse proxy does not by
+itself change this cookie attribute. The old native jar rejected the session
+cookie without `Secure`, so the successful login was followed by an unauthenticated
+API request. This was an app compatibility defect, not evidence of a bad password.
+
+Android 0.2.1 native preview (version code 3) keeps the cookie in its existing
+HTTPS-only, origin/port-bound jar. It still never makes HTTP requests, follows
+redirects or shares cookies with another server. System TLS validation,
+AndroidKeyStore encryption and absolute expiry remain unchanged. The native client
+does not depend on weakening the server or changing its configuration. For browser
+security, server operators should still use `SESSION_SECURE=true` on HTTPS sites.
+
+## Error distinctions
+
+- Rejected username/password: the server rejected `/auth/login` with HTTP 401.
+- Invalid/expired second-factor step: the verification endpoint rejected the code
+  or its pending session. Restart login if necessary.
+- Login confirmed but no usable cookie: inspect server/reverse-proxy cookie
+  configuration; no password-reset claim is made.
+- Login confirmed but session rejected: inspect server/proxy session handling.
+
+The app never displays raw cookie values, credentials or arbitrary server response
+bodies as diagnostics. A failed attempt's message is cleared after successful retry.
+If the updated app still fails, report the exact new message, app/server version,
+whether the direct browser password login works and whether 2FA is enabled.
+**Do not send passwords, session cookies, recovery codes or authentication tokens.**
+
+## Reproduction and regression evidence
+
+```sh
+python3 scripts/test-integration.py /path/to/pinned-upstream --android --cookie-without-secure
+python3 scripts/test-integration.py /path/to/pinned-upstream --android
+```
+
+The first mode fails with the old native jar despite successful protocol-level
+browser login. After the fix, it passes native login, a wrong-password/correct-retry
+sequence, dashboard/recreation, task/note/shopping operations and logout. The normal
+Secure-cookie mode remains required too. These use synthetic temporary records and
+the unmodified pinned upstream, not the user's server or credentials.
+
+Development APKs from different CI jobs can have different debug signing keys.
+If Android rejects an update as signature-incompatible, uninstall the old preview
+before installing the new one. This clears local app/session data and requires a
+fresh login; server household records are not deleted. Production signing remains
+paused and full native PWA parity is not implied by this fix.