Problem

s390x release binaries built on ARM64 embed the execution host architecture in buildInfo: distarch and target_arch are "aarch64". This causes jstests/sharding/query/pipeline_length_limit.js to expect 1000 stages while the correctly compiled s390x server returns 700.

Confirmed on v8.3-staging at 2a59d93a96806679bb14301d968498441771a294 and v9.0-staging at 78e4e61309ddf75f9596bfcca5bf969e67d812f2; tracked by BF-46763. The affected cross-compilation backports are SERVER-136176.

Root Cause

src/mongo/util/version_constants_gen.py uses platform.machine() for both architecture fields. bazel/config/generate_config_header.bzl already passes TARGET_ARCH from the target C++ toolchain, but the generator ignores it. The _s390x_ path and internalPipelineLengthLimit=700 are working.

Scope

• Affects master: No. Master already consumes target metadata, introduced in SERVER-132885 (05c7dbec4295cc0908adb422cab1bd337257ed46).
• Backport the narrowly scoped architecture metadata fix to v8.3 and v9.0.
• Apply the same fix to v8.0, which has the same generator logic, ahead of the cross-compilation backport BACKPORT-30093.
• Preserve native-build fallback behavior and add unit coverage for an ARM64 build host targeting s390x.

Acceptance Criteria

• Cross-built s390x binaries report distarch=s390x and target_arch=s390x.
• Release internalPipelineLengthLimit remains 700.
• pipeline_length_limit.js passes on native s390x test hosts.
• Unit tests cover target architecture metadata and native fallback.

Evidence

• v8.3 failing test log
• v9.0 failing test log