[EPIC] Make Termix Mobile a standalone local and remote-connected client

Goal

Evolve Termix Mobile from a client that depends on a reachable Termix backend into a dual-mode application that can:

1. run as a secure standalone client using local device storage and local protocol connections; or
2. connect to a remote Termix server and synchronize data and use server-proxied capabilities.

Users should be able to choose the connection origin per host or through a sensible default, similar to the desktop application. Loss of connectivity to the Termix server must not erase the configured server, destroy the authenticated session, or make locally available hosts unusable.

Parent scope

Local workspace

• encrypted local database for hosts, folders, credentials, snippets, preferences, and supported connection metadata
• encryption keys protected by Android Keystore / iOS Keychain and gated by the existing App Lock
• schema migrations, backup/recovery behavior, and explicit local-data deletion
• no plaintext secrets in AsyncStorage, logs, crash reports, or application backups

Local connection origin

• direct SSH terminal connections from the device
• direct SFTP/file-manager support
• local tunnels where mobile platform lifecycle restrictions permit them
• staged support for RDP/VNC, Docker, metrics, and other host capabilities where a maintained mobile-native implementation exists
• per-host connection origin: Local device or Remote Termix server
• actionable capability errors instead of silently falling back to a different origin

Remote server mode and synchronization

• initial import from a connected Termix server into the encrypted local workspace
• stable cross-database identities rather than numeric row IDs
• incremental pull/push synchronization when connectivity is available
• an offline mutation queue for supported create, update, move, and delete operations
• deterministic conflict handling, tombstones, retries, and idempotency
• clear sync state and last-successful-sync information in the UI
• opportunistic foreground/background sync within iOS and Android lifecycle limits

Authentication and device security

• preserve the server session through transient network failure and clear it only after confirmed authentication failure
• keep local App Lock separate from remote server authentication
• define behavior for expired tokens, disabled accounts, revoked devices, removed access, and remote data changes while offline
• allow a user to disconnect a remote server without accidentally deleting an independent local workspace

Delivery plan

This epic must be delivered as reviewable, independently testable PRs rather than one monolithic change:

1. architecture and threat model
2. encrypted local data layer and migrations
3. read-only host/folder/credential synchronization
4. offline startup and cached read-only UI
5. direct local SSH and SFTP
6. per-host Connection Origin selection
7. offline mutation queue and conflict handling
8. additional local protocols and operational capabilities
9. device revocation, recovery, migration, and end-to-end hardening

Acceptance criteria

• after first setup, the app can cold-start without reaching the configured Termix server
• App Lock can unlock the local workspace without requiring server URL, password, or TOTP entry
• cached data is available offline according to the current user/device authorization policy
• a host configured with Local device origin can establish a supported connection without routing through the Termix backend
• a host configured with Remote server origin continues to use the backend and reports unavailability honestly
• offline edits synchronize safely after reconnection without duplicating records or overwriting a concurrent change silently
• deleting or revoking a device prevents future remote synchronization and follows the documented local-data policy
• iOS and Android have automated coverage for storage/sync state machines and documented real-device protocol validation

Related existing work

• #450 — offline startup, local cache, and synchronization
• #1101 — local versus remote connection origin on Mobile

Non-goals

• shipping every desktop/server capability in the first PR
• storing decrypted credentials for convenience
• pretending iOS and Android allow unrestricted background services
• silently routing a Local connection through the remote server, or vice versa

No files or tests are named. Start by reading related issues #450 and #1101, then review the delivery plan and separate the architecture, storage, synchronization, connection, and security work into independently testable PRs. Done means each stage has documented scope, tests, and acceptance criteria without treating the epic as one change.