GhostIDE v2.38.0 - LAN TLS phase 1

GhostIDE v2.38.0 (versionCode 143) - LAN TLS phase 1

APK: ghostide-v2.38.0.apk, 20,324,970 B
MD5: 857ddc0053f3ef41da7e89316a7efb27
SHA-256: 7218b14298c01eb246ca74e0ff8357d7393e51ded42cbc420bf01f69e968a9cc
compileSdk/targetSdk 36, minSdk 24, same signing key as v2.37.0.
(APK asset not attached: the automation credential is scoped to api.github.com and uploads.github.com returns 401, same as prior releases. The APK itself is delivered to the owner directly.)

Phase 1 of the pair-mode encryption design (all six design decisions approved by the owner on Oct 22, 2026): LAN pairing on the desktop host is now encrypted.

What changed (desktop server.py; the phone remains a guest):

• In LAN mode the host runs dual listeners: the host's own UI stays on loopback plain HTTP and never sees a certificate warning; guests are served HTTPS on each LAN address with a persistent self-signed certificate (SANs: localhost plus the machine's private IPs; 10-year validity; stored in ~/.ghostide/tls with the key owner-only).
• The certificate's SHA-256 fingerprint is the host identity: it is printed in the server console at boot, shown in the pair panel, and served loopback-only at GET /api/pair/certfp. Guests compare it with the host screen before typing the pairing code. The code remains the secret; the fingerprint is public. The cert is regenerated only when the host's addresses outgrow it, and the console announces a changed fingerprint.
• Certificate generation prefers the cryptography package, falls back to the openssl CLI, and reports a crypto-path failure instead of silently degrading. If neither route exists, LAN mode still starts in plain HTTP with a loud console warning (an explicit design decision).
• PAIRING.md now documents the new trust model with its honest limits: encryption defeats passive observers and token replay; a browser guest who skips the fingerprint comparison can still be impersonated at first pairing. Android app-guest QR pinning is phase 2; host-confirm joins are phase 3.

Proof: new probe suite tools/probes/tls_probes.py passes 16/16 (generation, key permissions, fingerprint integrity, HTTPS join and API, certfp gating 401/403, wrong-cert refusal, persistence across restarts, plain-HTTP fallback with warning); both generation routes were live-tested. Full gates (foreground): 65/65 harness files, DOM-stub clean, JVM 18+14+6+14+25, probes hardening 19 / restore 41 / pair 36 / GH e2e 19 / TLS 16. Staged app.js byte-matches the built bundle.