feat: add --extension, --chrome-profile, --profile-directory options to test command

[shivamgupta021]

Summary

Adds three new web-only CLI options to maestro test:

Option	Maps to	Repeatable
--extension <path>	Chrome's --load-extension	yes
--chrome-profile <path>	Chrome's --user-data-dir	no
--profile-directory <name>	Chrome's --profile-directory	no (requires --chrome-profile)

Together these enable testing browser extensions and authenticated web apps without doing the OAuth dance inside every flow.

Addresses #2798 (which asked for --user-data-dir exposure in containerized environments). Same underlying gap — no way to configure ChromeOptions from the CLI — surfaces in both use cases.

Example

# Load an unpacked extension
maestro test --extension /path/to/unpacked-ext flow.yaml

# Run against a pre-authenticated profile
maestro test \
  --chrome-profile "/Users/me/Library/Application Support/Google/Chrome" \
  --profile-directory "Profile 1" \
  flow.yaml

# Combined: extension + authenticated profile (common when testing a
# Gmail/Slack/SaaS Chrome extension end-to-end)
maestro test \
  --extension /path/to/unpacked-ext \
  --chrome-profile /tmp/test-profile-snapshot \
  flow.yaml

Changes

Production code (4 files, +109/-30 LOC)

• maestro-cli/.../TestCommand.kt — three new @Options + internal fun validateChromeProfileOptions() called from call() (mirrors the existing screenSize validation pattern).
• maestro-cli/.../MaestroSessionManager.kt — threads the three params through newSession() → createMaestro() → both Platform.WEB branches of pickWebDevice().
• maestro-client/.../Maestro.kt — Maestro.web() accepts and forwards the three params (all default null).
• maestro-client/.../CdpWebDriver.kt — accepts the three new constructor params; extracted the inline ChromeOptions configuration into internal fun buildChromeOptions(): ChromeOptions so unit tests can inspect args without launching a real ChromeDriver. Empty-string flag values are treated as null.

Touched-but-trivial (2 files)

• maestro-client/.../DeviceService.kt — 1-line comment noting that the existing CdpWebDriver() call site relies on default-null params for the new options. No behavior change.
• maestro-web/.../ChromeSeleniumFactory.kt — non-goal comment explaining that the legacy Selenium driver intentionally does not receive these flags. No behavior change.

Tests (2 files, 17 new test cases)

• maestro-client/.../CdpWebDriverTest.kt (new) — 11 unit tests for buildChromeOptions(): arg presence per flag, ordering when combined, empty-string handling, omitted---profile-directory case.
• maestro-cli/.../TestCommandTest.kt — 6 new tests for validateChromeProfileOptions(): throws when --profile-directory set without --chrome-profile, throws when --extension path contains a comma (Chrome uses , as path separator with no escape), passes otherwise.

Docs

• CHANGELOG.md — three bullets under ## Unreleased.

Validation rules

1. --profile-directory requires --chrome-profile → CliError("--profile-directory requires --chrome-profile to be specified.")
2. --extension <path> rejected if path contains , → CliError("--extension path cannot contain commas (Chrome's --load-extension uses ',' as the path separator): <path>")

Both fire in TestCommand.call() before session creation, matching the existing --screen-size format check.

Compatibility

• All new CLI params default to null / unset; behavior with flags unset is byte-identical to upstream main.
• Existing positional/named call sites of Maestro.web(), MaestroSessionManager.newSession(), and CdpWebDriver(...) continue to compile and behave identically.
• No new Maven/Gradle dependencies.
• No edits to maestro-android/, maestro-ios/, maestro-orchestra/, maestro-studio/, or maestro-ai/ modules.

Test plan

• ./gradlew :maestro-client:test --tests "maestro.drivers.CdpWebDriverTest" passes (11/11)
• ./gradlew :maestro-cli:test --tests "maestro.cli.command.TestCommandTest" passes (incl. 6 new)
• ./gradlew :maestro-cli:installDist builds cleanly
• maestro test --help lists all three flags with (Web only) prefix; --profile-directory includes "Requires --chrome-profile"
• Manual integration: load a real Chrome extension against a pre-authenticated profile, run a smoke flow against Gmail — verified locally on macOS 14, Chrome 144.

Happy to iterate on flag naming, validation edge cases, or scope.