Unlisted packages are still installed via `dotnet tool install` without `--version` despite correctly not showing up in `dotnet tool search`

Describe the bug

A tool that was incorrectly versioned was pushed to NuGet.org and had to be unlisted. The version is correctly hidden from searches both via nuget.org and via dotnet tool search but dotnet tool install seems to ignore this and just locate the version via the provided v3-flatcontainer list

I can vaguely get on board with argument that if there are dependencies on that version then it shouldn’t break them by being completely inacessable, but shouldn’t that really only apply in that case if that specific version is requested via --version rather than by default? What’s the point of hiding it in the search if its still the one that is installed by default, that feels a little unexpected for the end user and potentially less safe.

It’s worth noting this also existed and since been fixed in NuGet.exe

To Reproduce

1. Publish two versions of a tool to nuget.org
2. Unlist the latest version
3. Run dotnet tool search <TOOLNAME> and validate that the unlisted version does not show up
4. run dotnet tool install --global <TOOLNAME> Result The later but, unlisted version is installed Expected The latest listed result is installed

Further technical details

This can be reproduced through the dotnet sdk container

> run --rm -it mcr.microsoft.com/dotnet/sdk:6.0 bash
> dotnet tool install --global Octopus.DotNet.Cli

using dotnet version 6.0.200

Update: 25 Feb I have since had to contact the NuGet team directly to get the package properly “deleted” so the specific package in this example is no longer a problem but the fundamental issue still remains.

[JiaqiWang18]

PR is up for this issue: https://github.com/dotnet/sdk/pull/28951

[clairernovotny]

We should ensure the semantics for this are the same as dotnet nuget add ...