fix(ci): make activation-e2e harness actually run its flows (#91)

Port the harness fixes from test/e2e-new-features to main so the
Activation E2E workflow stops failing before any flow executes:

- Run everything through scripts/run-e2e-flows.sh as a single script
  invocation: android-emulator-runner executes each 'script:' line in
  its own shell, so the previous 'cd artifacts/screenshots' never
  persisted and maestro failed with 'Flow path does not exist' on
  every run (19/19 red since the workflow landed).
- adb reverse + 127.0.0.1 instead of 10.0.2.2 (unreliable headless),
  emulator->mock reachability probe, logcat + maestro debug capture.
- Trim the flow list to the two flows that exist on main; the three
  newer flows land with the test/e2e-new-features PR.
- continue-on-error until the suite's first green: the positive flow
  still fails its final reply assertion (mode B in #90), and a
  never-green suite should not block unrelated PRs or pollute the
  product-intelligence failure metrics (#89).

Refs #90. Refs #89.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

.maestro/flows/activation-negative-401.yaml

@@ -39,20 +39,19 @@ name: Activation - negative path (connect-time 401 must surface a visible error)
 
 - tapOn:
     id: "connect-ip-input"
-- inputText: "10.0.2.2"
-- tapOn:
-    id: "connect-port-input"
-- eraseText
-- inputText: "4097"
+- inputText: "127.0.0.1:4097"
 - hideKeyboard
 - takeScreenshot: negative-S3_401_server_url_entered
 - tapOn:
     id: "connect-submit-button"
 
+# Matches the 40s margin used for the positive flow's connection-status-dot
+# wait (src/lib/sdk.ts REQUEST_TIMEOUT_MS = 30_000) for consistency, even
+# though --fail-auth responds with 401 immediately in practice.
 - extendedWaitUntil:
     visible:
       text: "Connection Failed"
-    timeout: 20000
+    timeout: 40000
 - assertVisible:
     text: "Connection Failed"
 - assertVisible:

.maestro/flows/activation-positive.yaml

@@ -8,7 +8,7 @@ name: Activation - positive path (consent -> connect -> send -> reply)
 #
 # The CI job starts `node tests/fixtures/mock-opencode-server.ts --port 4096`
 # on the runner host BEFORE this flow runs. The Android emulator reaches the
-# runner host via the standard emulator alias 10.0.2.2.
+# runner host via the standard emulator alias 127.0.0.1.
 
 - launchApp:
     clearState: true
@@ -29,20 +29,24 @@ name: Activation - positive path (consent -> connect -> send -> reply)
 - takeScreenshot: positive-S3_add_connection_form
 - tapOn:
     id: "connect-ip-input"
-- inputText: "10.0.2.2"
-- tapOn:
-    id: "connect-port-input"
-- eraseText
-- inputText: "4096"
+- inputText: "127.0.0.1:4096"
 - hideKeyboard
 - takeScreenshot: positive-S4_server_url_entered
 - tapOn:
     id: "connect-submit-button"
 
+# Quick Connect fires up to 3 sequential/parallel network calls before the
+# dot renders (testConnection's health(), then addConnection's parallel
+# project.current() + path.get()), and each individual fetch is capped by
+# src/lib/sdk.ts REQUEST_TIMEOUT_MS = 30_000. A 20s wait here raced that
+# 30s client-side timeout and flaked in CI (first real run, #82) even
+# though the mock server was up and reachable. 40s gives the app's own
+# timeout room to complete; this still asserts the real thing, just with a
+# wait that isn't shorter than the code path it's waiting on.
 - extendedWaitUntil:
     visible:
       id: "connection-status-dot"
-    timeout: 20000
+    timeout: 40000
 - assertVisible:
     id: "connection-status-dot"
 - takeScreenshot: positive-S5_connected