fix(cli): bind artemis batch to the requested device serial

[LunarECL]

Summary

• Fixes artemis batch ignores the requested device serial (no --device-serial; ADB_DEVICE_SERIAL / ARTEMIS_DEVICE_ID silently dropped) and can run goals on another phone #135.
• Symptom: with several devices attached, artemis batch ignores the requested device. There is no --device-serial option, and ADB_DEVICE_SERIAL / ARTEMIS_DEVICE_ID are silently dropped, so the goals run on whichever device the tool picks (first idle device via the daemon queue, first listed device standalone) while the batch still reports PASS.
• Root cause (two spots):
  • batch.py never passed a serial to submit_batch_to_daemon() (which already accepts device_serial) and never called for_device() on the standalone builder.
  • AgentConfigBuilder.build() copied the env serial into device_id but left device_platform as None; Agent._init_internal() falls back to get_first_device() when either field is missing.
• Fix: batch gains --device-serial/-s and threads it through both paths; an env-provided serial now defaults the platform to ANDROID, the same default for_device(str) already applies. Explicit for_device() / -s still win over the environment, and with no serial anywhere the first-device fallback is unchanged.
• Precedence is the one AgentConfigBuilder.build() already used: explicit value, then ARTEMIS_DEVICE_ID, then ADB_DEVICE_SERIAL. batch reads the environment in the same order, so with both variables set the CLI and the SDK config resolve to the same device (covered by tests on both routing paths).

Regression evidence

Ten new tests; six of them fail on 371aa6d and pass with this change (the other four pin the unchanged behaviour: no-serial fallback, explicit override, env precedence):

• Before (git checkout 371aa6d -- artemis/): uv run pytest tests/unit/test_cli.py -k device_serial -q → 4 failed; uv run pytest tests/unit/sdk/test_agent_config_builder_device.py -q → 2 failed, 2 passed
• After: uv run pytest tests/unit/test_cli.py -k batch tests/unit/sdk/test_agent_config_builder_device.py -q → 12 passed

On a real farm (6 Samsung devices over wireless adb, 10.60.0.101:5555 listed first), uv run artemis batch -f goals.txt -p flash -s 10.60.0.108:5555 now logs Device ID: 10.60.0.108:5555 on both the daemon path and --standalone; before the change both logged 10.60.0.101:5555.

Verification

• make test (uv run pytest) on this branch: 4 failed, 2197 passed, 6 skipped, 8 deselected (60.8 s)
• make test on untouched 371aa6d with only the new test files present: 6 failed, 2187 passed — the same 4 pre-existing failures plus the 2 new builder tests that are expected to fail before the fix
• uv run ruff check / uv run ruff format --check on the four changed files → clean
• uv run python scripts/quality_ratchet.py → unchanged (754 / 0 / 18)
• make typecheck → 0 errors, 0 warnings

Scope

• 4 files changed (2 source files, 2 test files)

Existing full-suite limitations

The 4 failures are identical on the untouched base commit on this machine (macOS 27 arm64, Python 3.12.13) and are unrelated to the batch/builder code paths touched here:

• tests/unit/mcp/test_adb_server_contract.py::test_adb_server_manifest_matches_fixture
• tests/unit/mcp/test_device_utils.py::test_ensure_emulator_uses_windows_creation_flags (see test_ensure_emulator_uses_windows_creation_flags can only pass on Windows #97)
• tests/unit/test_cli.py::test_cli_mcp_install_all
• tests/unit/test_cli.py::test_cli_mcp_install_codex_preserves_config_and_is_idempotent

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[LunarECL]

@googlebot I signed it!