fix(cli): don't buffer all Android emulator output in memory, report its output if it fails

[nicoburns]

Summary

dx serve --android (without --device) boots the first AVD in start_android_sim. The emulator was spawned with tokio's Command::output(), which unconditionally re-sets stdout/stderr to Stdio::piped(), overriding the Stdio::null() calls just above it (whose comment says they exist to "prevent accumulating huge amounts of mem usage"). So everything the emulator prints for its whole lifetime was collected into a Vec inside dx, and then dropped without ever being logged.

Now the emulator is spawn()ed with piped stdout/stderr, read line by line, and only the last EMULATOR_LOG_TAIL_LINES (20) lines are kept. If it exits unsuccessfully, dx logs a warning with the exit status and that tail, e.g.:

WARN Android emulator exited with exit status: 1:
INFO         | ...
FATAL        | Not enough space to create userdata partition. ...

Previously such a failure was completely silent under dx. stdin is now Stdio::null() rather than inherited.

The two .unwrap()s in the spawned task are replaced with warnings, so a missing/unrunnable emulator binary logs Failed to list Android emulators using ... instead of panicking the task.

Why the output is not forwarded to tracing

Forwarding each line with tracing::debug! was tried and rejected. In serve mode every trace event is pushed onto the TUI's unbounded channel regardless of level and filtered afterwards. With a stub emulator emitting 1GB of lines in interactive mode, dx RSS reached 7.6GB and was still growing, and the build was starved. Showing live emulator output at --verbose would need that channel bounded or filtered at the source first.

Context and what this does not claim

This came out of investigating a user report of a system-wide freeze about 15s after dx serve --android on NixOS/AMD (not reproduced). The emulator launch is the main thing serve does that build does not, and this bug was found while reading that path. It is not established that the buffering causes the reported freeze: on a healthy emulator (37.1.11, API 35 image, software rendering) the output was only about 10KB in 90s. It would only matter if the emulator logs heavily, e.g. in an error loop.

Testing

• Before (0.7.10), stub emulator writing 200MB to stdout: dx RSS rose from about 60-80MB to 258MB.
• After, stub writing 1GB of lines, interactive mode: build completes normally, dx RSS 516MB vs 474MB for the same run with no emulator output.
• Stub exiting with status 1: warning with exit status and the last 20 lines is logged.
• Missing emulator binary: warning logged, serve continues.
• Real emulator still boots from dx serve --example hello_world --android (adb devices shows emulator-5554, sys.boot_completed=1), and keeps running after dx exits (it ignores SIGPIPE; same as before this change).
• cargo fmt --all -- --check passes. cargo clippy -p dioxus-cli --all-targets reports no warnings in the changed code.

A single emulator output line with no newline is still buffered whole until its newline arrives.

Link to Devin session: https://dioxus.staging.devinenterprise.com/sessions/a52f9de27c0f464e89601c0520cf9486
Open in Devin Desktop: https://dioxus.staging.devinenterprise.com/desktop/session/a52f9de27c0f464e89601c0520cf9486?variant=devin-insiders
Requested by: @nicoburns

[staging-devin-ai-integration]

I'll fix CI failures and address comments from users with write access that start with 'Devin'.

• Disable automatic comment, CI, and merge conflict monitoring