fix(server): derive module name for UI test bundles in xcresult parser

What changed

The xcresult parser now derives a test case’s module name from "UI test bundle" nodes in addition to "Unit test bundle" nodes, at both node-classification sites in XCResultParser.

Why

xcrun xcresulttool get test-results tests reports unit test bundles with nodeType: "Unit test bundle" and UI test bundles with nodeType: "UI test bundle". The parser only matched the former, so every UI test case was parsed with a nil module and grouped under the "Unknown" fallback, which is what gets stored as module_name.

Root cause and impact

Quarantine skipping breaks when the stored module is wrong:

• Test case identity is the deterministic UUID of (project_id, name, module_name, suite_name).
• The CLI builds xcodebuild -skip-testing arguments from the stored module name.
• With module_name = "Unknown", the CLI emits -skip-testing Unknown/Suite/method. xcodebuild silently ignores skip identifiers whose target does not exist, so the quarantined UI test keeps running and failing in CI.

Unit tests were unaffected because their module name was parsed correctly. This matched a report of quarantined (skipped) UI tests still running and failing in CI, where the affected tests showed Module: Unknown.

Why this fix

The fix is at the single source of the wrong data, the node-type classification, rather than papering over "Unknown" downstream in the CLI or server matcher. Correcting the parsed module fixes both the broken -skip-testing matching and the Module: Unknown display.

Caveats for rollout

• Not retroactive. Existing UI test cases already stored under "Unknown" keep that identity. Once the corrected module name is parsed they reappear as new test cases, so they must be re-quarantined.
• This NIF is baked into the xcresult-processor Tart VM image, so the fix takes effect only after that image is rebuilt and rolled, not on a normal server deploy.

Validation

Developed TDD-style:

1. Added a test that drives canned xcresulttool JSON (one unit test bundle and one UI test bundle) through the public parseTestStatuses(path:) API via an injected CommandRunning stub that mimics the tool’s file-redirect. It failed first with the UI test’s module resolving to nil, while the unit test assertion already passed.
2. Applied the fix. The test passes.
3. Full XCResultParser suite green (8/8), no regressions.

The test exercises the real public API with dependency injection, so no private visibility was widened.

How to test locally

cd server/native/xcresult_nif
swift test --replace-scm-with-registry --filter parseTestStatuses_derivesModuleNameForUITestBundlesNotJustUnitTestBundles

Revert either classification site in Sources/XCResultParser/XCResultParser.swift to the "Unit test bundle"-only check to see the test fail.