Mobile first run: serve the dashboard without the chain, show real progress

[MudDev]

Problem

On a phone the first run was bad, and an existing install could stop loading at all:

• Fresh install: the node deferred dashboard.epix until the xID light client had a trust pin, and the UI showed a 404 "Looking up this name" page (older builds: the raw text "could not resolve dashboard.epix"). The bootstrap probed 4 RPCs one after another with 20 s timeouts, so this was minutes over Tor and never ended with fewer than 2 RPCs reachable.
• Existing install with the chain unreachable: every light-client advance invalidated the cached name binding, so the next boot had to ask the chain, and with a pin installed a failed lookup failed boot ("EpixNet could not start").
• The dashboard was never pre-granted ADMIN, so a fresh install got the "This xite requests permission" prompt over an empty list and the refused feedQuery crashed the feed.
• Loading-screen dead ends: every failure said "No peers found", the Tor wait before a clone was invisible, no retry, jargon on WebSocket loss.

Changes

Node (epix-node, epix-ui, epix-chain)

• Boot never touches the chain. A cached name serves at once; a name whose binding was superseded serves the saved copy as verified:false and is re-verified in the background; dashboard.epix with nothing on disk resolves to the compiled-in dashboard address (what epix-server already launches by) and downloads from peers with no RPC at all. Legacy/unbound cache entries stay misses in finality mode.
• On-demand resolution waits for trust and the network instead of failing, publishes a per-host resolveStatus (state + reason), retries with backoff, and is woken by the new networkRetry command and the shells' network_changed().
• A "not found" from one RPC is never a verdict (no proof behind it): retried slowly, never persisted, never switches a name. Only a proven answer moves the homepage name, and the old xite loses the alias.
• ADMIN is granted automatically only to the compiled-in dashboard address, never to whatever a name resolves to.
• Light client: parallel bootstrap probes with 10 s timeouts, a status cell exposed in serverInfo.xid_trust (phase, sources reachable, last error), TrustNotEstablished before any HTTP, and the RPC list is re-read every cycle so a Config-page change takes effect without a restart (phones cannot restart).
• Clone failures carry a reason (no_peers, tor_unavailable, offline, files_unavailable, content_unverified); the Tor wait before a clone pushes waiting_tor / tor_skipped events.
• serverInfo.launch { display, address, verified, deferred }.
• certXid's on-chain identity discovery is bounded to 8 s, so a xite's account picker never hangs on "Checking..." while the registry is unreachable.
• The waiting_tor event is re-pushed every few seconds during the Tor wait before a clone (the single push went out before the page's socket was open).

Wrapper (ui/media/all.js, all.css, wrapper.html)

• Resolving mode replaces the 404 page: the same loading screen shows "Connecting to the network / Checking the Epix name registry / Looking up X" with plain-language reasons, a Retry button and a Connection settings button, and reloads itself when the name lands.
• Honest failure texts by reason, a "Connecting to Tor" stage, a 30 s no-peers watchdog, "Reconnecting to EpixNet..." instead of the UiServer wording, the home button hidden on the dashboard's own loading screen, "Connection settings" corner link.
• A "Downloading content... N files from K peers" pill for any xite whose posts live in per-user files and stream in after the page opened (forums, blogs, mail): shows from the first user-content file event, hides 12 s after the last one. Generic, so third-party xites get it without changes.
• The resolving screen offers a Connection settings button (to the Config page) whenever changing a setting could be the way out: no name servers reachable, repeated name-server failures, offline mode, Always-Tor without Tor.

Shells

• Android: error page shows the node's own error with "Try again" (boots again in place) and "Reset connection settings and try again" (sets private/config.json aside, kept as config.json.broken-<time>); no dead 15 s port wait after a failed boot; a "No internet connection" line; the splash covers the page area in the page's colour so the hand-off does not flash; a bare word in the address bar opens <word>.epix; Tor "failed" has its own badge colour; the node is told when the network comes back.
• iOS: the same error/retry/reset contract, a splash guard, a page for provisional load failures, an NWPathMonitor hook. Not built here.

Verified on the Small_Phone emulator (debug APK)

• Fresh install: launch to dashboard in about 5 s, no prompt, no feed error (was about 28 s with the 404 page and the prompt).
• Fresh install with every chain RPC dead (dead endpoints in config): dashboard in about 2 s by address while xid_trust.state stays establishing.
• Airplane mode with the resolve cache deleted: the dashboard opens from the saved copy at once; 5 s after the network returns the name is re-verified and the cache rebound.
• Fresh install offline: the resolving screen reports 0/4 name servers reachable; 1.5 s after the network returns it resolves and loads by itself.
• talk.epix from the address bar: resolved in about 1 s, Epix Talk up in about 4 s. With dead RPCs it shows "Can't reach the Epix name servers ... change the servers in Connection settings" with Retry and Connection settings; changing the servers on the Config page and tapping Retry resolves it within seconds.
• Corrupt config: error page with the cause; "Try again" recovers once the file is fixed; "Reset connection settings" sets it aside and boots with defaults.
• Opening the published Epix Talk on a fresh install: the loading screen, then the page with the wrapper's "Downloading content... N files" pill counting up while the topics fill in.
• Tests: cargo test -p epix-chain 86/86, -p epix-node 38/38, -p epix-ui 359/360 (the failure is the timing-flaky EDX commit test, passes alone).

Scope note

Everything is in the node, the wrapper and the shells; no xite needs a change. Earlier companion PRs against EpixDash-Xite and EpixTalk-Xite were closed for that reason.

Follow-ups

• The iOS shell changes need an Xcode build.
• The pre-existing same-origin WebSocket binding (any xite's script can open a socket bound to the dashboard address) was flagged in review; it is unchanged by this PR since the dashboard was already granted ADMIN by every user, but worth a per-render token later.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud