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

### Describe the bug

*This is likely the underlying cause of https://github.com/dotnet/sdk/issues/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:

```yml
- 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 `, 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 `. 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 `, it will fail because it only sees the .NET 8 SDK. Even if you run `/home/runner/.dotnet/dotnet ` 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