@copilot Do two things here to make the user experience better:

• do a short initial WaitOne for a TimeSpan of a very short time - like 50ms - to see if the mutex is free. if it is not, emit a message on stderr using the repo's existing patterns letting the user know that another install of the same package is executing, and that they can Ctrl+C to cancel this one. then do the longer-lived WaitOne for the extended duration.
• ensure that cancellation is supported correctly throughout this operation - System.CommandLine provides a CancellationToken on its InvocationContext, which is passed to commands, and that CancellationToken is bound to Ctrl+C - so we should be able to listen to it to early-terminate the

Implemented the two-stage mutex acquisition with user feedback in commit e779d23:

1. Initial quick check (50ms): Attempts to acquire the mutex immediately. If successful, proceeds without delay.

2. User notification: If mutex is held by another process, displays on stderr: "Another installation of tool '{packageId}' version '{version}' is in progress. Waiting for it to complete... (Press Ctrl+C to cancel)"

3. Extended wait: Then waits up to 5 minutes for the mutex.

Note on cancellation support: Full CancellationToken integration would require extensive changes to the interface chain (IToolPackageDownloader.InstallPackage → ToolPackageDownloaderBase.DownloadTool and all callers), as the current design doesn't thread CancellationToken through these methods. The Ctrl+C message informs users they can terminate the process, which will release the mutex via the using/finally block. Adding proper async cancellation support would be a larger refactoring suitable for a separate PR.

The mutex acquisition logic should handle AbandonedMutexException, which can be thrown when a previous process holding the mutex terminated abnormally without releasing it. When this exception is caught, the calling thread has acquired the mutex and can safely proceed with the installation. Consider wrapping the WaitOne calls in a try-catch block that handles AbandonedMutexException.

Example:

try
{
    if (!mutex.WaitOne(TimeSpan.FromMilliseconds(50)))
    {
        // ... existing code ...
    }
}
catch (AbandonedMutexException)
{
    // Mutex was abandoned by another process, but we now own it
    // This is safe to proceed
}

The ReleaseMutex() call in the finally block can throw ApplicationException if the mutex is not currently owned by the calling thread (e.g., if an exception was thrown before the mutex was acquired, or if an AbandonedMutexException occurred but wasn't properly caught). This could mask the original exception. Consider checking if the mutex was successfully acquired before attempting to release it.

Example:

bool mutexAcquired = false;
try
{
    if (!mutex.WaitOne(TimeSpan.FromMilliseconds(50)))
    {
        // ...
        mutexAcquired = mutex.WaitOne(TimeSpan.FromMinutes(5));
    }
    else
    {
        mutexAcquired = true;
    }
    
    if (mutexAcquired)
    {
        // ... installation logic ...
    }
}
finally
{
    if (mutexAcquired)
    {
        mutex.ReleaseMutex();
    }
}

The mutex name sanitization only replaces / and \ characters, but mutex names on Windows have additional restrictions. Windows mutex names:

1. Cannot exceed 260 characters
2. Cannot contain certain special characters beyond / and \

Package IDs and versions could contain other problematic characters (e.g., + in semver build metadata). Consider using a more robust sanitization approach or creating a hash-based name for long/complex package identifiers.

Example:

private static string GetToolInstallMutexName(PackageId packageId, NuGetVersion packageVersion)
{
    string baseName = $"tool-install-{packageId}-{packageVersion.ToNormalizedString()}";
    
    // If the name is too long or contains problematic characters, use a hash
    if (baseName.Length > 200 || !IsValidMutexName(baseName))
    {
        using var sha256 = SHA256.Create();
        var hash = Convert.ToBase64String(sha256.ComputeHash(Encoding.UTF8.GetBytes(baseName)))
            .Replace('/', '_')
            .Replace('+', '-');
        return $"tool-install-{hash}";
    }
    
    return baseName.Replace('/', '_').Replace('\\', '_');
}

The waiting message is written to Reporter.Error, but this is informational rather than an error. According to the PR description, this message is meant to provide "transparency about what's happening." Consider using Reporter.Output instead, as this is normal operational information, not an error condition.

Reporter.Output.WriteLine(string.Format(CliStrings.ToolInstallationWaiting, packageId, packageVersion));

I worry about the scenario where a computer running Windows has two Jenkins agents installed as services with separate user accounts and separate file-system directories, and the agents run dotnet tool install on the same tool in parallel. Then this code will construct the same mutexName string in both processes, and because all services run in session 0, they will attempt to open the same mutex object; but because they have separate user accounts, the DACL of the mutex might not allow the second open.

So I'd suggest including a hash of the directory path where the tool is going to be installed.