"dotnet tool install" and "dotnet <toolname>" inconsistent treatment of paths and DOTNET_ROOT

[SteveSandersonMS]

Describe the bug

This is likely the underlying cause of #43670 but I have more info about the issue now so filing a new issue for re-triage.

When installing .NET global tools, it seems to ignore DOTNET_ROOT and cares only about the path to the dotnet binary you invoked.
When invoking .NET global tools, it seems to ignore the path to the dotnet binary you invoked and cares only about DOTNET_ROOT.

Impact: this makes it hard to use .NET global tools with Copilot Coding Agent, which matters to us a lot.

To Reproduce

Repo containing repro: https://github.com/SteveSandersonMS/ExampleMcpServerUsage

I've been running into trouble using .NET global tools with Copilot Coding Agent because:

1. In the CCA runtime environment it has .NET 8 installed by default at /usr/lib/dotnet
2. I actually need to use .NET 9
3. So in the build steps I'm using the following:

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 9.0.x

4. That adds a new .NET installation at /home/runner/.dotnet

Now, if you try to do dotnet tool install <some-dotnet-9-tool>, it will fail because it only sees the .NET 8 SDK. Even if you set the env var DOTNET_ROOT to /home/runner/.dotnet, this still fails - it seems to ignore DOTNET_ROOT entirely. The only thing that worked for me is running /home/runner/.dotnet/dotnet tool install <some-dotnet-9-tool>. So it seems it does care about the path to the dotnet installation you're calling.

But then if you try to run your tool with dotnet <some-dotnet-9-tool>, it will fail because it only sees the .NET 8 SDK. Even if you run /home/runner/.dotnet/dotnet <some-dotnet-9-tool> it fails - it seems to ignore the path to the dotnet installation you're calling entirely. The only thing that worked for me is setting DOTNET_ROOT to /home/runner/.dotnet.

Hopefully you can see how these two paragraphs are inconsistent with each other. Ideally:

• Min bar: both installation and invocation should respect DOTNET_ROOT
• Better still: also, if DOTNET_ROOT is not set, then they should both respect the path to the installation that you ran