fix: preserve capability alternatives from option lists

[lucasmariano003-wq]

Description

Remote(options=[first, second]) is already accepted by the Appium constructor's type signature, but Selenium's generated W3C envelope is wrapped again as an appium:capabilities capability. The server receives one empty firstMatch entry instead of the requested alternatives.

Normalize each option's capability names before Selenium extracts common values, then preserve its alwaysMatch/firstMatch envelope. Normalizing first also prevents the default automationName and an explicit appium:automationName override from ending up in conflicting sections. Caller-owned options, nested capabilities such as proxy, and client connection settings are preserved.

Validation

• Four new regressions fail against the original source and pass after this fix: shared/nested capabilities, automation-name overrides, different platform alternatives, and a single-item list versus one options object.
• A real localhost HTTP fixture captures the POST emitted by Remote. It confirms the corrected envelope, unchanged input options, and preservation of the supplied AppiumClientConfig and timeout. This tests request serialization and session-response handling; it does not claim physical-device or multi-driver negotiation.
• All 177 unit tests passed.
• make check passed Ruff, formatting, and Mypy over 320 source files.
• Both published files were fetched back and their hashes match the tested copies.

OpenAI Codex performed the implementation and local validation for this GitHub account; maintainer review is pending.

If accepted, please confirm whether this PR qualifies for compensation under the Appium contributor compensation scheme and the applicable amount. I understand that classification and payment remain at the project's discretion.

[lucasmariano003-wq]

Thanks for the approval. I traced the remaining iOS failure on b1986724c9996ef9278022f490eb7d10f556c97a to WDA startup. The Appium server log records xcrun simctl launch --terminate-running-process ... com.facebook.WebDriverAgentRunner.xctrunner timing out after 600,000 ms, followed by wdaStartFailed. The client consequently hits its existing 600-second timeout during test_context fixture setup.

The next test sends an identical session payload, successfully starts WDA, and passes Safari navigation. The job ends with one passed test and one setup error. The simulator had also required two boot retries.

The Safari fixture uses a single XCUITestOptions object. I compared its actual HTTP requests using the base and PR implementations: the payloads and client timeout are unchanged. All 177 unit tests and make check pass locally. I have left the approved code unchanged. Could a maintainer re-run the failed iOS job on this head?

[KazuCocoa]

yes, that is fine.