flagcx: take the library from the installed package, not a source tree

[tengqm]

The flagcx wheel ships the ctypes facade as flagcx.api, next to
libflagcx.so under the package's own lib/:

flagcx/_C.cpython-312-x86_64-linux-gnu.so
flagcx/api.py
flagcx/__init__.py
flagcx/lib/libflagcx.so

A backend that installs the wheel therefore has no source tree to point
FLAGCX_PATH at, and every place that reached for the FlagCX Python API
assumed one. The package root only re-exports the compiled bindings, so the
names below have to come from flagcx.api rather than flagcx.

The change is additive: flagcx.api becomes the primary import, and the
existing FLAGCX_PATH-driven resolution stays as the path for a source tree.
No import path is renamed and no new environment variable is introduced.

Imports

Three call sites imported plugin.interservice.flagcx_wrapper after appending
FLAGCX_PATH to sys.path. Each now tries flagcx.api first and falls back
to the wrapper. The fallback is what FLAGCX_PATH still guards, so a source
tree keeps working:

• vllm_fl/distributed/device_communicators/flagcx.py
• vllm_fl/distributed/kv_transfer/flagcx_connector.py
• vllm_fl/dispatch/backends/vendor/sunrise/patch.py

The connector's ImportError message now names both shapes instead of telling
the reader to set FLAGCX_PATH.

Library resolution

FLAGCXLibrary already resolves the .so on its own — FLAGCX_PATH, then the
installed package's lib/, then a source build tree, then ldconfig — so the
hand-assembled <FLAGCX_PATH>/build/lib/libflagcx.so paths are gone. The
communicator still threads its library_path argument through for callers that
pass one; the connector called the same join with no argument, so it now calls
FLAGCXLibrary() and lets the ladder resolve it. That is also the fix for the
wheel-only case, where the old join produced os.path.join(None, ...).

FLAGCX_LIB_PATH is removed. It existed only to override the hand-built
path above; with the ladder in FLAGCXLibrary it has no job left, and keeping
it would mean carrying a second way to say what FLAGCX_PATH already says.

Backend selection

platform.py selected the flagcx dist backend on "FLAGCX_PATH" in os.environ, which is how a source tree announced itself. A wheel-only install
has no such variable, so it fell through to nccl. _flagcx_backend_enabled()
now accepts either shape: FLAGCX_PATH set, or the flagcx distribution
importable.

Test gates and docs

has_flagcx() in conftest.py and the two distributed test modules probed
only <FLAGCX_PATH>/build/lib/libflagcx.so. They now probe the installed
package first, and accept lib/libflagcx.so as well as build/lib/… so a
meson-layout source tree is not reported missing.

examples/disaggregated_serving_xpyd/run_flagcx_connector.md taught a source
build; it now installs the wheel and drops the FLAGCX_PATH exports, keeping
a sentence on how to point at a source build instead. The FLAGCX_PATH row in
vllm_fl/dispatch/README.md is reworded the same way.

Verification

End-to-end on metax124 (MACA 3.8.1.3, vLLM 0.24.0 +flagos empty wheel,
Qwen3-4B, TP=2): both ranks select backend=flagcx with no FLAGCX_*
variable set in the environment — the wheel-only shape, which is the case
that previously fell through to nccl.

The flagcx wheel came from the vendor index, not a local build:
flagcx-0.14.0rc2.post2.dev4+maca3.8.1.3.20260914.g08ab373-cp312-cp312-linux_x86_64.whl
installed by pip with an empty direct_url.json, resolving
flagcx/lib/libflagcx.so from site-packages. The names imported here
(FLAGCXLibrary, buffer_type, flagcxComm_t, flagcxDataTypeEnum,
flagcxUniqueId, flagcxRedOpTypeEnum) are all defined in that wheel's
api.py.

Note for anyone reproducing this: the metax path additionally needs the vLLM
0.24.0 compatibility fixes, which are unrelated to this PR and tracked
separately (#377).

This PR was written in part with the assistance of generative AI.