Fix config mismatch for targets under multiple top-level parents

[arrizer]

Fix config mismatch for targets under multiple top-level parents

Problem

Each top-level target (app, extension, test) gets its own Bazel settings transition hash — the -ST-<hex> suffix in the configuration mnemonic (e.g., ios_sim_arm64-dbg-ios-sim_arm64-min16.1-ST-90f37f7dbff2).

A dependency shared between multiple top-level targets (e.g., a library used by both the main app and an extension) appears in the aquery result with the ST hash of whichever top-level target compiled it. However, platformBuildLabelInfo may return a different top-level target's config mnemonic (via bspUriToParentConfigMap), causing the exact mnemonic match in getTargetAction to fail.

This produces a continuous stream of "No relevant target actions found for <target>. This is unexpected." errors.

The issue affects both Swift and C/ObjC targets. Any dependency that exists under multiple top-level targets with different ST hashes can be affected — this includes common libraries, not just obscure external dependencies.

Root cause

In getTargetAction, the config mnemonic filter requires an exact string match:

return config.mnemonic == platformInfo.topLevelParentConfig.configurationName

Two top-level targets with the same platform/arch/minOS but different build settings produce different ST hashes. The cquery and aquery may associate the same dependency with different top-level parents, creating a mismatch between the stored parent config and the available aquery actions.

Fix

When the exact mnemonic match finds no candidates, fall back to matching with the -ST-<hex> suffix stripped. This preserves the platform/arch/minOS constraint while tolerating ST hash differences across top-level targets.

The fallback only runs when the exact match already returned zero results, so the happy path is unchanged. For C/ObjC files, the per-file -c argument filter runs after the fallback to ensure the correct source file is matched across all ST variants.

After all filtering, multiple remaining candidates are different ST variants of the same platform/file combination their compiler args are effectively identical, so we pick the first.

Changes

• Added ST-hash fallback in getTargetAction when exact config mnemonic matching fails
• Replaced multipleTargetActions error with candidateActions.first — after the fallback + file filtering, remaining duplicates are benign ST variants
• Extracted -ST-<hex> stripping into String.strippingSettingsTransitionHash with documentation linking to the Bazel config transitions docs

[rockbruno]

I think #195 might fix this issue (some of the label parsing was wonky)