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.

SECURITY.md

@@ -16,8 +16,11 @@ server vulnerabilities belong in its private reporting channel.
 - Passwords and second-factor codes exist transiently for the API request; they
   are not saved to preferences, keychains, logs, artifacts or application state
   restoration. Server cookies, not passwords, persist the session.
-- Android persists allow-listed Secure cookies with their absolute expiry in
-  AES-GCM ciphertext backed by AndroidKeyStore, with the origin authenticated as
+- Android treats every allow-listed native cookie as HTTPS-only, bound to the
+  configured origin/port. This also applies when upstream omits the `Secure`
+  attribute (`SESSION_SECURE=false` is upstream's default); no HTTP transport is
+  enabled. Persistent cookies retain their absolute expiry in AES-GCM ciphertext
+  backed by AndroidKeyStore, with the origin authenticated as
   additional data. iOS uses a private ephemeral URLSession jar and origin-scoped
   Keychain items protected with WhenUnlockedThisDeviceOnly.
 - CSRF tokens follow the upstream API protocol. Only an explicit `csrf_invalid`