bazel_build_iceoryx2_qnx8 crate feature is unconditionally enabled regardless of target platform, breaking consumption as a Bazel dependency

[hskang-amelia]

Summary

src/kyron/BUILD and src/kyron-foundation/BUILD unconditionally set the
bazel_build_iceoryx2_qnx8 crate feature on libkyron / libkyron_foundation,
with no select() gating on target platform:

# src/kyron/BUILD
rust_library(
    name = "libkyron",
    crate_features = selects.with_or({...}) + [
        "bazel_build_iceoryx2_qnx8",
        "tracing",
    ],
    ...
)

# src/kyron-foundation/BUILD
rust_library(
    name = "libkyron_foundation",
    crate_features = [
        "bazel_build_iceoryx2_qnx8",
        "tracing",
    ],
    ...
)

Via rules_rust's crate_universe feature unification, this activates the qnx8
Cargo feature on the transitive iceoryx2-pal-posix crate, which conditionally
compiles a small C shim (socket_macros.c) — for every build of kyron,
regardless of whether the actual target platform is Linux or QNX.

Impact: breaks consumption as a Bazel dependency from another repo

This is invisible when building kyron standalone (via cargo build, or via
bazel build //... inside kyron's own devcontainer/CI), but it breaks when
score_kyron is added as a Bazel dependency to a sibling repo that registers
its own (minimal/hermetic) C/C++ toolchain — because Bazel toolchain
resolution is invocation-global, not scoped per bzlmod module. The consuming
repo's toolchain ends up being used to compile kyron's iceoryx2-pal-posix
C shim too.

Reproduction

Tested against eclipse-score/communication (which registers its own
gcc_toolchain with a deliberately minimal sysroot for its C++ mw::com
code):

1. Add to communication/MODULE.bazel:

   bazel_dep(name = "score_kyron", version = "0.1.3", dev_dependency = True)
   local_path_override(module_name = "score_kyron", path = "../kyron")

2. bazel mod deps --lockfile_mode=update
3. bazel build @score_kyron//src/kyron-foundation:libkyron_foundation

Result — fails before any kyron Rust source is even compiled:

cargo:warning=src/c/socket_macros.c:23:24: error: no include path in which to search for sys/select.h
cargo:warning=src/c/socket_macros.c:26:1: error: unknown type name 'size_t'
cargo:warning=src/c/socket_macros.c:27:12: error: implicit declaration of function 'CMSG_SPACE'
...
error occurred in cc-rs: command did not execute successfully (status code exit status: 1):
  .../gcc_toolchain_x86_64/xbin/gcc" ... "-nostdinc" ...
  ".../crate_index__iceoryx2-pal-posix-qnx8-0.7.0/_bs.out_dir/01f2103c15c31950-socket_macros.o"

The consuming repo's hermetic toolchain simply doesn't have general POSIX
headers (sys/select.h, sys/socket.h, fd_set, ...) — reasonably so, since
it was curated only for that repo's own C++ code, not for building kyron's
transitive dependencies.

Suggested fix

Gate bazel_build_iceoryx2_qnx8 (and the corresponding iceoryx2_qnx8 /
iceoryx2_cal_qnx8 / iceoryx2_bb_derive_macros_qnx8 deps) behind an actual
target-platform select() instead of applying it unconditionally — similar in
spirit to the QNX platform-triple label fix already applied on the
score-crates / rules_rust fork side. On a non-QNX target platform this
feature (and its iceoryx2 QNX variant deps) shouldn't be requested at all.

Environment

• kyron: verified against v0.1.3 (latest release) and current main
  (cc72f599cc0c04a4e80c12a204f57e59a48d284a) — both identical on the
  BUILD files in question, bug present in both. Consumed via
  local_path_override from communication at registry version 0.1.3.
• rules_rust 0.68.1-score
• Reproduced inside ghcr.io/eclipse-score/devcontainer:latest

[hskang-amelia]

Follow-up after actually reading iceoryx2-pal-posix's Cargo.toml/build.rs (via the qorix-group/iceoryx2 fork this repo vendors, iceoryx2-pal/posix/) — the root-cause description above isn't quite right, so correcting it here before anyone acts on it:

• There is no Cargo feature named qnx8 on iceoryx2-pal-posix. Its [features] are just libc_platform and std.
• The socket_macros.c compile (build.rs:18-75) isn't QNX-specific either — it runs for essentially every real target_os (Linux included) whenever the libc_platform feature is off, which is the default. So this isn't "QNX code leaking into a Linux build"; it's that this crate always needs a working C toolchain (bindgen + cc) unless libc_platform is enabled, and Bazel's toolchain resolution being invocation-global (not per-module) is what routes a consumer's own minimal/hermetic C++ toolchain into compiling this shim.
• crate_features = ["bazel_build_iceoryx2_qnx8", ...] in this repo's own BUILD files is a marker kyron/kyron-foundation use for their own internal #[cfg(...)] branches (prelude.rs, ipc/iceoryx2/mod.rs) — it doesn't set any feature on iceoryx2-pal-posix itself.

Given that, gating this repo's own crate_features/deps with a select() (mirroring the existing //src/flags:enable_ipc pattern) wouldn't actually fix the underlying issue, since score-crates' MODULE.bazel (crate.spec/crate.annotation for iceoryx2-pal-posix-qnx8, currently no crate_features set) doesn't publish an alternative build of this crate with libc_platform enabled to select into. Filing that as a separate issue on score-crates instead, since that's where the actual fix looks like it belongs.

[hskang-amelia]

Follow-up: the fix landed as a PR against score-crates rather than here — eclipse-score/score-crates#73 (tracked in eclipse-score/score-crates#72).

No code change needed in kyron itself. Once that PR merges, bumping this repo's score_crates bazel_dep pin should resolve this issue.