fix(mobile): route phone APIs to selected profile and unblock runtime readiness

apps/desktop/docs/mobile-profile-routing-20261007.md

@@ -0,0 +1,32 @@
+# Mobile connection repair — beta.19
+
+The paired phone previously resolved the desktop's active profile. If that
+profile's startup promise was waiting for first-run setup, every phone API
+request waited too, even while the default backend was already serving.
+
+REST and WebSocket requests now resolve the phone's explicit `profile` query
+(default when absent). Aggregate `profile=all` reaches the default process
+without rewriting the downstream query. Invalid profile identifiers, remote
+backends and a missing local runtime are refused; phone requests do not install
+software or silently fall back to a different profile. Resolution has an eight
+second deadline; this is not an agent, tool or scheduled-job execution deadline.
+
+Shared-runtime completion wakes only a waiting setup for the same runtime root.
+Primary startup then resolves its own profile again. This does not grant
+installation consent or substitute a sibling profile's backend connection.
+
+## Evidence
+
+- 94 mobile transport, certificate, relay, profile and startup regression tests.
+- Electron TypeScript type check.
+- Opt-in `mobile-live.test.ts`, with `AITURK_TEST_BACKEND_PORT`: real local
+  backend behind the production TLS proxy, pinned certificate, screen reads,
+  cron create/update/pause/resume/delete and chat WebSocket ping. Test-created
+  job is deleted; existing jobs are untouched. This test does not trigger an
+  agent job or claim physical-phone/cellular acceptance.
+- Public relay hello was separately exercised using Android's production
+  OkHttp/Conscrypt stack. A successful hello alone does not prove API readiness.
+
+Publication, installed beta.19 and physical-phone acceptance are separate gates.
+Existing phone security exclusions are unchanged. Unsupported methods and
+features are not claimed to be implemented by this connection repair.