Add NCCL task protocol trace metadata

[sanrise]

Description

Adds per-task NVTX protocol metadata so the executed NCCL protocol (LL / LL128 / Simple) is visible in profiles. Today the kernel symbol is named after the inlined LL body, not the tuned protocol, so the only way to see the real protocol is NCCL_DEBUG_SUBSYS=TUNING, which is too noisy for normal profiling. This pushes one NVTX range per scheduled collective task, named with its protocol, plus a compact structured payload (comm, rank, bytes, collective, algorithm, protocol, dtype, root, channels) stored as enum integers to keep the launch path cheap. nsys then reports the executed protocol per task, even when protocols are fused into one launch.

torch.profiler / Kineto does not decode external NVTX payloads; those consumers should read protocol from the NCCL profiler plugin (unaffected here).

Related Issues

Part 1 of 2 for #2196. Part 2 removes the misleading kernel protocol suffix and should merge after this: #2224

Changes & Impact

• Adds an internal NVTX schema and a per-task range + structured payload pushed at launch (src/enqueue.cc, src/include/nvtx.h, src/include/nvtx_payload_schemas.h).
• No public API changes.
• No effect when NVTX is disabled (early return on ncclParamNvtxDisable).

Performance Impact

• Binary size: libnccl.so +~11 KB (+0.02%); dynamic symbol count unchanged.
• all_reduce_perf 8 B–64 MiB, forced Simple/LL/LL128: flat vs baseline.
• Correctness check: forced NCCL_PROTO shows the matching NVTX range, and the payload protocol byte matches the enum (02 Simple, 00 LL, 01 LL128).

[sanrise]

@xiaofanl-nvidia any comments/feedback on this?

[MoraruMaxim]

I have a few comments. The answer to some of them can be just "we are ok with that"

• NCCL already has NVTX instrumentation at the API level, so with this PR we would have some duplication (e.g., the communicator id, message size). It might actually make sense to duplicate some of this information for clarity, but we need to decide.
• Currently the label only contains the protocol name. We should decide what the label must indicate. Additionally, we should use the existing ncclProtoToString function (instead of adding code duplication with ncclNvtxProtoRangeName).
• The current PR does not expose the redop in the kernel task payload, even though it is exposed by the existing API-level NVTX instrumentation in NCCL (for AllReduce, Reduce, ReduceScatter).
• We should run more experiments to evaluate the profiling overhead, in particular at small message sizes.

[xiaofanl-nvidia]

@MoraruMaxim please work with @armratner to provide feedback to the PR author to improve and get to a merge-able state. Then you can mirror it for merging. Thanks!