[ba6ul]

Refs #46

What

AdbClient honours ANDROID_ADB_SERVER_PORT, and new process-level tests run the real daemon against the fake adb server to check the #14 failure paths that were only verified by reading code.

Why

The daemon always used port 5037, the same port as the developer's real adb server, so testing it end to end meant stopping or replacing that server. Four #14 paths had no automated check: an invalid scrcpyPath during auto-launch, the p key, the u key, and adb that cannot be restarted.

How

• AdbClient({int? port}) defaults to AdbClient.defaultPort: ANDROID_ADB_SERVER_PORT if it is a valid port (1 to 65535), else 5037. An explicit port: still wins. parsePort is a static function so the rule is unit-testable. With the variable unset nothing changes.
• ensureServerRunning() now runs adb -P <port> start-server, so a client pointed at another port can never start a server on 5037. For port 5037 this is the same as before.
• test/support/daemon_harness.dart starts bin/daemon.dart as a child process with ANDROID_ADB_SERVER_PORT set to the fake server, APPDATA and HOME set to a temp folder (so the real config and known-devices file are neither read nor written), and a free IPC port written to that temp config. It captures the log, can type keys on stdin, and asks for listDevices over IPC to prove the daemon is alive and serving.
• daemon_process_test.dart: five scenarios. Each waits for the guard's specific log line and then checks IPC still answers. The two adb-restart scenarios wait for "could not start the adb server" twice, so they prove the retry loop keeps running rather than that the process merely survived (the last-resort zone in main would keep IPC up even if the loop died).
• README: one sentence on how the process-level tests stay isolated.
• Not changed: how the daemon finds adb or scrcpy (Resolve vendor/ from the executable; do not persist auto-detected paths #30), and no test stops, starts or talks to a real adb server.

Verified by

• dart analyze clean in core, ipc, daemon. Tests: core 27 (21 + 6), ipc 26, daemon 76 (71 + 5) pass locally on Windows; the five process tests take about 25 s together. CI results are in the checks below, including the first run of these on Ubuntu.
• Core tests: parsePort for valid, missing, malformed, zero, negative, too large and decimal values; explicit port wins; and a stand-in adb script recording its arguments shows ensureServerRunning runs -P <port> start-server when nothing is listening, and runs nothing when a server answers.
• Sensitivity check: with the try/catch around ensureServerRunning() removed from the daemon's retry loop, the two adb-restart scenarios fail; with it they pass. The code was restored afterwards.
• The real adb server on this machine was never involved: the same process (PID 15620) was listening on 5037 before and after the runs.
• Not verified: the Ubuntu run before CI; the chmod-based stand-in script is only exercised there.

Risk / follow-ups

• The harness runs the daemon from the current directory, so the tests must be run from packages/daemon (as project.json and the README do).
• A temp folder may linger on Windows if a file is still held when the test ends; it is only a temp folder.
• The scenarios cover what the daemon logs and that it stays up; they do not yet check the UI-facing failed events for these paths.