`xls_cc_embed_data`: shared-library link fails on macOS — ELF-only `-soname` passed to the Mach-O linker

## Summary

`xls_cc_embed_data` produces both a static and a shared library. Linking the shared variant fails on macOS, because the toolchain passes the ELF-only `-soname` flag to `ld64.lld`:

```
ERROR: xls/common/BUILD:286:18: Linking xls/common/libsubprocess_helper_embedded.dylib failed:
ld64.lld: error: unknown argument '-soname=libxls_Scommon_Slibsubprocess_Uhelper_Uembedded.dylib'
clang++: error: linker command failed with exit code 1
```

Mach-O uses `-install_name` rather than `-soname`.

## Impact

Any **test** target that depends on embedded data cannot be built on macOS, because tests link their dependencies dynamically by default. Concretely, `//xls/common:subprocess_test` cannot be built at all.

Tool binaries are unaffected — they link the static object — so this is easy to miss: `bazel build` of the main tools succeeds while `bazel test` of an affected target fails.

## Reproduction

On macOS arm64:

```
bazel test -c opt //xls/common:subprocess_test
```

## Suggested fix

Embedded data is only ever linked statically into its consumers, so the shared library is an unused artifact. Passing `disallow_dynamic_library = True` to the `cc_common.create_linking_context_from_compilation_outputs()` call in `xls/build_rules/xls_cc_embed_data_rules.bzl` avoids producing it — which sidesteps the broken link on macOS and drops a dead artifact on every platform.

Verified locally on macOS arm64: `//xls/build_rules/tests/...` passes 31/31 (including `embed_data_test`), and `//xls/common:subprocess_test` then builds and passes.

If you would rather fix this in the toolchain configuration so the shared variant links correctly on Mach-O, that works too — I took the minimal route. Happy to send a PR either way.

## Related

#1434 (tracking issue: OS X aarch64 build/test status), and #4991 (the `subprocess.cc`
macOS issue) -- both are needed before
`//xls/common:subprocess_test` can be built and run on macOS.

Also #1363 (macosx nightly builds are failing), which reports the symptom; this issue is one of the concrete causes.

## Environment

- macOS 26.6.2, arm64 (Apple Silicon)
- Bazel 8.7.0, XLS at `fc572666a`

Start in xls/build_rules/xls_cc_embed_data_rules.bzl at the cc_common.create_linking_context_from_compilation_outputs() call, then inspect the embedded-data build rule and its shared-library outputs. Run xls/build_rules/tests/... and bazel test -c opt //xls/common:subprocess_test; done means the rule tests pass and the macOS subprocess test builds and passes without the ELF-only linker error.

Written by the indexing model from the issue text.