Fix nuget subcommand --help forwarding to NuGet CLI

[Copilot]

Fixes #53673

dotnet nuget add source --help (and all nuget subcommand help) showed the generic System.CommandLine help for the nuget command instead of forwarding to the NuGet CLI. Regression in 11.0 SDK.

Root Cause

DotnetHelpBuilder.Write() used this guard to detect NuGet commands:

if (command.GetRootCommand() is NuGetCommandDefinition)

GetRootCommand() traverses all the way to the actual CLI root (DotNetCommandDefinition), so this check is always false. The code falls through to base.Write(context), showing the generic System.CommandLine help for the nuget command.

Fix

Replace the broken check with a proper ancestor traversal:

if (IsInNuGetCommandTree(command))

private static bool IsInNuGetCommandTree(Command command)
{
    if (command is NuGetCommandDefinition) return true;
    if (command.Parents.FirstOrDefault(p => p is Command) is Command parent)
        return IsInNuGetCommandTree(parent);
    return false;
}

This correctly handles all cases:

• Unregistered subcommands like nuget add source (where the matched command is NuGetCommandDefinition itself, with unmatched tokens)
• Registered direct subcommands (NuGetDeleteCommandDefinition, etc.)
• Deeply nested subcommands (NuGetTrustAuthorCommandDefinition, etc.)

[marcpopMSFT]

Confirmed locally. Tested in codespaces with a few different nuget commands and it works well there.

[Copilot]

Pull request overview

Fixes a regression in the .NET 11 SDK where dotnet nuget <subcommand> --help displayed generic System.CommandLine help instead of forwarding to the NuGet CLI help output.

Changes:

• Replaces the incorrect GetRootCommand()-based NuGet detection with an ancestor traversal (IsInNuGetCommandTree).
• Ensures NuGet help forwarding triggers for both registered and unregistered (unmatched-token) NuGet subcommand paths.