feat(verify): borrow an emulator on a CI runner when the machine cannot run one

.claude/skills/verify-clerk-android/features/README.md

@@ -29,7 +29,7 @@ Clerk's test mode makes all of this safe to type into the real app.
 
 The names come from `source/ui/src/main/java/com/clerk/ui/ClerkTestTags.kt`. They are internal test hooks and may change.
 
-On the standard instance an email sign-in starts on the email-link screen ("Check your email"), so a spec switches to the email code through `Use another method`. For a phone sign-in, tap `clerk.auth.start.identifierSwitcher`, fill `clerk.auth.start.phoneNumber` with the ten digits of the seeded user's phone, and continue. A user with a password sees the password screen first and reaches the SMS code through `Use another method`. For sign-up, launch with `authMode: 'signUp'`, fill the email from `host.newEmail()` into `clerk.auth.start.identifier`, continue, fill the run password into `clerk.auth.signUp.password`, continue, then type the code into `clerk.auth.signUp.code`.
+On the standard instance an email sign-in for a user with no password goes straight to the email code screen ("Check your email"). The email link is off there. For a phone sign-in, tap `clerk.auth.start.identifierSwitcher`, fill `clerk.auth.start.phoneNumber` with the ten digits of the seeded user's phone, and continue. A user with a password sees the password screen first and reaches the SMS code through `Use another method`. For sign-up, launch with `authMode: 'signUp'`, fill the email from `host.newEmail()` into `clerk.auth.start.identifier`, continue, fill the run password into `clerk.auth.signUp.password`, continue, then type the code into `clerk.auth.signUp.code`.
 
 ## Feature entry contract
 
@@ -46,4 +46,4 @@ Each feature file starts with an H1 title and one paragraph describing the user-
 - [Session tasks](./session-tasks.md) covers the setup-MFA and choose-organization tasks after sign-in, the setup-MFA task after sign-up, and finishing the setup-MFA task with an authenticator code.
 - [Organizations](./organizations.md) covers creating an organization from OrganizationSwitcher.
 
-Not mapped: a password sign-in past the password screen, completing the setup-MFA task with an SMS code, social providers (no real OAuth on emulators), passkeys, and biometrics.
+Not mapped: a password sign-in past the password screen, the email link (off on the standard instance), completing the setup-MFA task with an SMS code, social providers (no real OAuth on emulators), passkeys, and biometrics.

.claude/skills/verify-clerk-android/features/sign-in-email-code.md

@@ -1,26 +1,26 @@
 # Sign in with an email code
 
-An existing user enters their email, asks for a one-time code instead of the email link, and signs in with the code.
+An existing user enters their email, gets a one-time code, and signs in with the code.
 
 ## Sub-features
 
-- `complete` reaches the email code screen for an existing test user through `Use another method`, stays on it, types `424242`, and lands signed in.
+- `complete` reaches the email code screen for an existing test user straight from Continue, stays on it, types `424242`, and lands signed in.
 
 ## How to get to it (user POV)
 
-- Open sign-in, type the email, tap Continue. On the standard instance the email-link screen ("Check your email") opens first. Tap `Use another method`, then `Email code to <email>`.
+- Open sign-in, type the email, tap Continue. On the standard instance a user with no password lands on the email code screen ("Check your email"). Type the code.
 
 ## Driving it with verify
 
 Preconditions:
 
 - The spec seeds a `+clerk_test` user on the standard instance and launches with `authMode: 'signIn'`, then taps `e2e.auth.signInFullScreen`.
 
-- **Request code.** Run `e2e-tests/bin/control-clerk-android run sign-in-email-code/complete`. It fills `clerk.auth.start.identifier`, taps `clerk.auth.start.continue`, waits for `clerk.auth.signIn.useAnotherMethod`, taps it and `clerk.auth.signIn.alternativeMethod.email_code`, expects `clerk.auth.signIn.code`, and expects it still on screen 3 seconds later, with the email on the code screen. Screenshot `code-screen`.
+- **Request code.** Run `e2e-tests/bin/control-clerk-android run sign-in-email-code/complete`. It fills `clerk.auth.start.identifier`, taps `clerk.auth.start.continue`, expects `clerk.auth.signIn.code`, and expects it still on screen 3 seconds later, with the email on the code screen. Screenshot `code-screen`.
 - **Complete.** After the code screen it fills `CLERK_TEST_CODE` and waits for the home to show `Signed in as` the seeded user's email with that user's ID. Screenshot `signed-in`.
 - **Proof.** The spec passes, and screenshot `signed-in` shows the home with the seeded user's email and ID.
 
 ## Gotchas
 
-- The spec checks the code field a second time after 3 seconds. A sign-in that shows the code screen for a moment and then returns to the email-link screen would pass a single visibility check.
-- The email-link screen and the email code screen both have the title "Check your email". The code field, `clerk.auth.signIn.code`, tells them apart.
+- The spec checks the code field a second time after 3 seconds. A sign-in that shows the code screen for a moment and then leaves it would pass a single visibility check.
+- The standard instance has the email link off, because a test address gets no mail, so a run has no link to follow. With the link on, AuthView opens the email-link screen first. It has the same title as the code screen, "Check your email", and no code field, so `clerk.auth.signIn.code` tells them apart. A spec that needs the link declares `auth_email.sign_in_strategies` in a settings file.

.claude/skills/verify-clerk-android/references/cli.md

@@ -3,9 +3,9 @@
 ## Verbs and flags
 
 ```console
-e2e-tests/bin/control-clerk-android doctor [--backend auto|local] [--live]
-e2e-tests/bin/control-clerk-android up [--backend auto|local] [--wait <seconds>]
-e2e-tests/bin/control-clerk-android run <feature | feature/spec | path.e2e.ts>... | --all [--backend auto|local] [--grep <regex>] [--retries <n>] [--github-report] [--no-video] [--wait <seconds>]
+e2e-tests/bin/control-clerk-android doctor [--backend auto|local|remote] [--runner <label>] [--live]
+e2e-tests/bin/control-clerk-android up [--backend auto|local|remote] [--runner <label>] [--wait <seconds>]
+e2e-tests/bin/control-clerk-android run <feature | feature/spec | path.e2e.ts>... | --all [--backend auto|local|remote] [--runner <label>] [--grep <regex>] [--retries <n>] [--github-report] [--no-video] [--wait <seconds>]
 e2e-tests/bin/control-clerk-android screen [--png]
 e2e-tests/bin/control-clerk-android attach <run-id> --pr <n> [--screenshot <label>]...
 e2e-tests/bin/control-clerk-android down [--stale] [--dry-run]
@@ -15,14 +15,15 @@ Every verb takes `--json` and then prints one `{ "ok": ... }` object. Exit codes
 
 `--github-report` is for a CI job. After the run, `run` hands the results of every settings group to `@e2e-dev/github` as one report. The reporter writes that report to the job summary. When the event of the job names a pull request and the step has a `GITHUB_TOKEN` that may write pull request comments, it also posts one comment and updates that same comment on later runs. `run` prints one `github` line that says what the reporter did, the reporter never changes the exit code, and nothing is reported for a run whose files hold a secret. Without the flag, `run` reports nothing to GitHub.
 
-`--backend auto` is the default and leaves the choice to the CLI.
+`--backend auto` is the default and leaves the choice to the CLI. `--runner` names the runner label of a remote session. With the local backend it is a usage error, and `doctor` takes it only with `--live`.
 
 ## `--wait`
 
 - `--wait` bounds the wait for a free lane in the machine-wide pool, and separately the wait for another verb in this worktree that is driving the device. Each wait gets the full budget. The default is 0, so a full pool fails at once.
 - It does not bound the wait for an `up` already running in this worktree. `run` waits for that `up` with no limit and prints that it is waiting.
 - Waiters get no turn order. When a lane frees, any waiting worktree can take it.
 - When the budget runs out, the verb exits 3 with `POOL_FULL` or `DEVICE_BUSY`.
+- A remote session has no lane pool, so there `--wait` only bounds the wait for another verb in this worktree.
 
 While it waits, the CLI prints a `wait` line naming each lane and the worktree that holds it, prints it again when that changes, and prints `still waiting after <n>s` every minute otherwise.
 

.claude/skills/verify-clerk-android/references/instances.md

@@ -4,7 +4,7 @@
 
 ## The standard settings
 
-`src/core/instances/base.json` defines the standard instance, with everything that can coexist switched on: email code, email link, phone code, password, username, TOTP, backup codes, organizations, and social buttons. It has two parts.
+`src/core/instances/base.json` defines the standard instance, with everything that can coexist switched on except the email link: email code, phone code, password, username, TOTP, backup codes, organizations, and social buttons. The email link is off so that an email sign-in opens on the code screen. It has two parts.
 
 - `config` is the whole body of the Platform API request that puts an instance on the standard settings.
 - `environment` lists the 62 leaves of the instance's public `/v1/environment` that a spec cannot run without. One of them, `user_settings.actions.delete_self`, has no `config` key. A new application lets a user delete their own account, and the check fails if Clerk changes that.