feat: add mobile paths for Android Termux and iOS a-Shell

[gabsprogrammer]

WhatsApp.Video.2026-04-13.at.17.30.29.mp4

[Lightheartdevs]

Appreciate the ambition and the scope discipline on docs — the mobile preview paths are clearly marked as beta and the detection gating is thoughtful. But this is too big and too risky to land as a single PR from a first-time contributor.

Blocking concerns:

1. Scope: 6,891 additions spanning Android (Python server + HTML/CSS/JS UI), iOS (C++ WASM runner + build scripts), a new dispatcher wrapper, new docs, and tests. This is three separate product bets in one PR:

   • Android Termux path (Python server + localhost UI)
   • iOS a-Shell WASM path (C++ runtime build + prebuilt binary)
   • Installer dispatcher refactor touching desktop install.sh

2. Committed binary artifact: dream-server/mobile-runtime/ios-ashell/bin/llama-cli.wasm is checked in (additions:0, deletions:0 — so it's a binary blob counted outside the diff stats). Binaries in git are a reproducibility and supply-chain concern. Options:

   • Build it in CI from the included ios-wasm-runner/ C++ source, commit SHA256 only.
   • Host it as a GitHub Release artifact, have the installer fetch it at install time with SHA check.
   • Git LFS if you really want it in the repo (but still not ideal).
     The current state — a binary nobody but the author can reproduce — shouldn't ship.

3. Desktop install.sh shebang change: #!/bin/bash → #!/bin/sh with re-exec to bash. The re-exec logic looks correct, but changing the shebang on the primary install entrypoint for every user to support iOS is the tail wagging the dog. Consider a separate install-mobile.sh entrypoint documented in the README, leave desktop install.sh alone.

4. Platform detection false-positive surface: ASHELL env var, TERM_PROGRAM==a-Shell, and the /var/mobile/Containers/Data/Application path matcher. If any desktop user has ASHELL set for an unrelated reason, they get routed to the mobile installer. Unlikely but not impossible — a stricter multi-signal gate would reduce risk.

5. Maintenance surface: Android Python server is 1,645 lines, Android UI is ~2,300 lines of JS/CSS/HTML, iOS C++ runner is ~700 lines. That's a new subsystem in languages the project didn't previously ship, and the SUPPORT-MATRIX implies ongoing support. Who owns this after merge?

6. All CI green is suspicious given the scope — mobile paths aren't being smoke-tested in CI. Adding at least a lint/syntax-check pass for the mobile installer would catch regressions.

Recommendation: split into 4 PRs.

1. Installer dispatcher + platform detection (common.sh, dispatch.sh changes, install.sh shebang). Gets reviewed as an infrastructure change.
2. Android Termux preview (installers/mobile/android-*, android-local-ui/, dream-mobile.sh for Android). Reviewed as a new product surface.
3. iOS a-Shell preview (ios-* scripts + C++ runner + build scripts). Reviewed with emphasis on the binary question.
4. Docs + README mobile sections. Lands after 1-3 are in.

Happy to re-review each piece. The work is interesting and I don't want it to languish, but landing this as one PR hides too many decisions. Thank you for the submission.