fix(android): give an adopted emulator the 60s bundle window of a new one

[janicduplessis]

Description

A debug stim android on an emulator adopted from the pool got only the 20-second bundle window, while a newly created emulator gets 60 seconds. Adoption cold-boots the parked AVD and wipes the app's data before install, so the first launch is as slow as on a new emulator. Under heavy host load the app's first bundle request arrives after the 20 seconds are up. The launch is then reported as launched: 'unverified' with launch remedies, even though it is working.

I reproduced this with this worktree's apps/mobile on the real ~/.stim (load average 100 to 150), adopting the parked stim-1700-mobile. On an adopting run retried after a boot timeout, Stim reported UNVERIFIED ... within 21s, and the app's bundle_response_started reached port 8084 about 57s into what a 60s window would have covered. The first adopting run only just stayed inside 20s: it reported 'bundling', with the request at 18s after launch.

The "Metro served the bundle 1.5 min earlier" in the issue was most likely Stim's own warmup (bundle_prefetch_*), which correctly does not count as evidence. The original workspace has been removed, so I can't confirm this from its logs.

Solution

An owned local emulator now gets the 60-second window when this run creates it or finishes adopting it: device.created || device.adoptionPending. The check is adoptionPending and not adopted, because a retry after a failed adopting run gets the device back from config with only adoptionPending. That retry still wipes and reinstalls the app, and it is the case I reproduced. The verify phase names the case: (new emulator) or (adopted emulator).

Only the window changes. The evidence required for true, 'bundling' and 'unverified' is the same, and so are the remedies. An emulator whose adoption finished on an earlier run keeps 20 seconds, as do rebooted owned AVDs, remote targets and physical devices. The lifecycle guide and website/docs/dev-server-and-logs.md are updated to match.

Test plan

• android-command.test.ts, launch verification table: I added two rows for an adopting emulator. With the bundle delivered at 23s the result is true after 26s. With no bundle the result is unverified after 60s. Both rows fail against main's launch.ts (unverified after 20000ms) and pass with this change.
• Real tool path: I ran this branch's dist/cli.mjs android on the emulator above, and the result was bundle loaded, process alive (14.4s total). That run reused the already-adopted emulator, so it took the 20s path. Re-parking to rerun adoption needed a worktree remove and re-add, and that was not permitted in this session. The adoption runs described above are the evidence for the window itself.
• format:check, lint, build, typecheck, knip, test:runtime and test:e2e (99/99) pass. In pnpm test, unrelated files hit 5s timeouts at load 300 to 500. Each of those files passed when rerun on its own.

Fixes #1792