iOS builds fail transitively: valdi_module()'s target_compatible_with resolves against the calling repo, and this repo never declares platforms

Title

iOS builds fail transitively: valdi_module()'s target_compatible_with = ["@platforms//os:ios"] resolves against the calling repo, and Valdi_Widgets never declares platforms as its own bazel_dep

Summary

Any downstream consumer that depends (even transitively) on a Valdi_Widgets module built via the shared valdi_module() macro fails to build for iOS with:

ERROR: no such package '@@[unknown repo 'platforms' requested from @@valdi_widgets~]//os': The repository '@@[unknown repo 'platforms' requested from @@valdi_widgets~]' could not be resolved: No repository visible as '@platforms' from repository '@@valdi_widgets~'

valdi_module() (defined in Valdi's own bzl/valdi/valdi_module.bzl) sets target_compatible_with = ["@platforms//os:ios"] on the generated iOS objc_library target. Since this Label string is evaluated at macro-expansion time in the context of whichever BUILD.bazel file calls the macro — not the repo where the macro is defined — every module in Valdi_Widgets that uses valdi_module() (e.g. valdi_standalone_ui) needs @platforms visible in Valdi_Widgets' own repo mapping. It is not: Valdi_Widgets' MODULE.bazel has no bazel_dep(name = "platforms", ...) of its own, and relies entirely on whatever its bazel_dep(name = "valdi") happens to pull in — which bzlmod does not expose transitively for this kind of macro-internal label resolution.

The failure only surfaces once a downstream consumer's own iOS target transitively depends on a Valdi_Widgets valdi_module() target (in our case //modules/ayab_valdi:ayab_valdi_objc → @valdi_widgets//valdi_modules/valdi_standalone_ui:valdi_standalone_ui_objc), so it is easy to miss until someone actually tries an iOS build.

Repro

1. A consuming project with bazel_dep(name = "valdi_widgets") and any module that depends on a Valdi_Widgets valdi_module() target (directly or transitively — valdi_standalone_ui is enough).
2. bazel build //:some_ios_app_target.
3. Observe the error above, citing whichever Valdi_Widgets-owned objc target sits in the dependency chain.

Root cause

valdi_module.bzl's Starlark macro body contains the literal string "@platforms//os:ios" (or similar) passed straight into a target_compatible_with attribute, rather than a Label("@platforms//os:ios") constructed at valdi_module.bzl's own load time (which would always resolve against Valdi's repo mapping, where platforms presumably is available, regardless of which package calls the macro). Any module that calls this macro must independently carry platforms as a direct bazel_dep.

What we did locally

Added bazel_dep(name = "platforms", version = "0.0.5") to our own project's MODULE.bazel — this fixes it for our own modules, but has no effect on Valdi_Widgets' own repo mapping, so anything depending on a Valdi_Widgets valdi_module() target for iOS still fails. We have not found a workaround that does not involve patching Valdi_Widgets' MODULE.bazel directly (analogous to the android_mvn gap we already carry a local patch for).

What we would like

Either:

1. valdi_module.bzl construct its target_compatible_with Labels via Label(...) at Valdi's own load time, so the constraint resolves against Valdi's repo mapping regardless of the caller, or
2. Valdi_Widgets' own MODULE.bazel declare bazel_dep(name = "platforms", ...) directly, matching what any other valdi_module() consumer needs to do today.

Environment

• Bazel 7.6.1, bzlmod
• Valdi_Widgets pinned at eaf2af1682c406abfa87ebf5c87d01dd44e14c9c
• Valdi pinned at 8776dbd68e369efb168deb7688f10dddde8cb121

Start by reading bzl/valdi/valdi_module.bzl and Valdi_Widgets' MODULE.bazel, then reproduce the failure with the downstream iOS target described in the issue. Trace the valdi_standalone_ui dependency and verify that the chosen fix makes @platforms resolvable for Valdi_Widgets-owned targets and the downstream iOS build complete successfully.