* fix(wheel): exclude libfabric/libefa from auditwheel bundle
The wheel build runs `auditwheel repair`, which by default grafts every
non-excluded shared library the extension links against into the wheel's
`.libs/` directory and rewrites RPATH to prefer the bundled copy. The
exclude list already carves out the system RDMA/EFA stack (libibverbs,
libmlx5, libnuma, libcuda, ...) but missed libfabric and libefa.
As a result a pip-installed wheel ships its own
`mooncake_transfer_engine.libs/libfabric-<hash>.so.1` and `engine.so`
loads that instead of the system `/opt/amazon/efa/lib/libfabric.so.1`.
On AWS EFA hosts this puts two independent libfabric instances in one
process: Mooncake uses the bundled one, while aws-ofi-nccl (loaded by
NCCL) uses the system one. Each instance runs its own `ofi_hmem_init`
and opens EFA devices independently. When Mooncake initializes first it
claims the EFA device context; aws-ofi-nccl's later `fi_getinfo` then
returns "provider efa output empty list" and NCCL silently falls back to
the TCP provider (169.254.170.x), which hangs cross-node collectives
such as `all_gather_object`.
libfabric is the one library that MUST be shared with the system
aws-ofi-nccl plugin, so it has to come from the system just like
libibverbs/libmlx5 already do. Excluding it (and libefa) makes the wheel
load the same libfabric the rest of the EFA stack uses, eliminating the
dual-instance conflict.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
3a1117bccc