NCCL encryption key would leak into PyTorch traces

Proposed PyTorch support for encrypting NCCL collective traffic would store the pre-shared key in plain text inside compiler traces, graph-cache entries, and reproduction scripts, an automated review found, breaking a guarantee that the key is never logged.

The change adds the key on NCCL process-group options and through a new environment variable. On the current NCCL path it is applied once when a communicator is created. Shrinking a group is meant to copy the key into the replacement communicator, or abort that communicator if construction throws.

The leakage is the one issue marked blocking. A second problem is easier to miss: if PyTorch is using the legacy NCCL backend or torchcomms, a set environment variable is silently ignored and traffic goes out unencrypted, while setting the same key on the options object raises. Documentation notes the difference, but a security setting that fails open on one path and closed on another is a configuration trap. Setting the variable only after a first keyless group also makes every later group fail, and on lazy pair groups that error shows up at the first point-to-point operation rather than at startup.