Pac tool PRT ignores NuGet.Config sources and requires direct nuget.org access

[brett-smith1]

Description

pac tool prt fails in environments where direct access to nuget.org is
restricted, even when NuGet is configured with an approved package-feed proxy.

PAC appears to contact https://api.nuget.org/v3/index.json directly instead
of honoring enabled sources in the user's NuGet.Config.

Environment

• PAC CLI: 2.12.2+ga6b1ffa
• OS: Windows
• Installation: .NET global tool
• Command: pac tool prt
• Package: Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool

NuGet configuration

• nuget.org is configured but disabled by organizational policy.
• An approved NuGet v3 proxy source is enabled.
• The PRT package is available through that proxy.
• Standard NuGet operations can use the proxy successfully.

Actual behavior

Running pac tool prt or pac tool list attempts to load:

https://api.nuget.org/v3/index.json

It then fails with:

Unable to load the service index for source
https://api.nuget.org/v3/index.json.

The SSL connection could not be established.
Authentication failed because the remote party sent a TLS alert:
'HandshakeFailure'.

Expected behavior

pac tool should support restricted enterprise environments by doing one or
more of the following:

1. Honor effective NuGet.Config package sources and disabled sources.
2. Support a --source option such as:
   pac tool prt --source <NuGet-v3-source>
3. Support a documented environment variable for overriding the tool package
   source.
4. Honor standard NuGet proxy and credential-provider behavior.

PAC should not require direct nuget.org access when the package is available
from an approved mirror or upstream proxy.

Workaround

Downloading the signed package
Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool from the configured proxy
and extracting its tools/net48 contents works successfully.

The important distinction is that this is not merely an HTTP proxy problem:  pac tool  ignores the effective NuGet package sources and disabled-source policy. Include that wording so the request is routed as package-source configurability rather than generic network troubleshooting. Do not attach credentials or the    section from your NuGet configuration.