dotnet tool/new search hardcode NuGet.org instead of honoring configured sources

### Describe the bug

NuGet-related CLI commands behave inconsistently when `nuget.org` is disabled and a replacement feed is enabled:

* `dotnet package search`, restore, audit, outdated/deprecated checks, and `dotnet tool install` use the enabled replacement feed successfully.
* `dotnet tool search` requires the exact `https://api.nuget.org/v3/index.json` source, refuses the replacement feed, and returns exit code 0 despite not performing the search.
* `dotnet new search` always searches NuGet.org and does not honor the configured package sources or expose a source override.

This is related to #55791, which demonstrates another SDK path accessing NuGet.org when it is unavailable.

### Steps to reproduce

Configure the machine as follows:

```console
$ dotnet nuget list source
Registered Sources:
1. nuget.org [Disabled]
https://api.nuget.org/v3/index.json
2. azure-default [Enabled]
https://packagefeedproxy.microsoft.io/nuget/v3/index.json
```

Confirm that general package search works through the replacement feed:

```console
$ dotnet package search Newtonsoft.Json --exact-match --take 3
Source: azure-default (https://packagefeedproxy.microsoft.io/nuget/v3/index.json)
...
```

`dotnet tool install` also works through that feed:

```console
$ dotnet tool install dotnetsay --tool-path ./tools --no-cache
Tool 'dotnetsay' (version '3.0.3') was successfully installed.
```

Run tool search:

```console
$ dotnet tool search dotnetsay --take 3
The 'dotnet tool search' command unconditionally accesses nuget.org to find tools, but it is not present in your nuget.config. Add it to run this command.
This can be done with this command:
dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org

$ echo $?
0
```

I also tested an enabled source named `nuget.org` whose URL was the replacement feed:

```console
Registered Sources:
1. nuget.org [Enabled]
https://packagefeedproxy.microsoft.io/nuget/v3/index.json
```

`dotnet tool search` produced the same error, indicating that it requires the exact NuGet.org endpoint rather than a source with that name.

Template search has the opposite behavior:

```console
$ dotnet new search aspire
Searching for the templates...
Matches from template source: NuGet.org
...
```

`dotnet new search --help` describes the command as "Searches for the templates on NuGet.org" and provides no source option.

### Expected behavior

NuGet-based search commands should honor enabled package sources, or expose an explicit source option. A disabled NuGet.org source should not be required or bypassed.

If `dotnet tool search` cannot perform the requested search, it should return a nonzero exit code.

### Actual behavior

* `dotnet tool search` refuses all replacement feeds, requires the exact NuGet.org endpoint, and reports success through its exit code after failing.
* `dotnet new search` uses NuGet.org independently of the configured package-source policy.

### Is this a regression?

The `dotnet tool search` behavior reproduces with all installed stable and preview SDKs tested:

* 9.0.312
* 10.0.300
* 11.0.100-preview.7.26381.103

I do not know whether an older SDK honored alternate sources.

### Workarounds

* If the tool package ID is already known, `dotnet tool install` works through the configured replacement feed.
* `dotnet package search` can search the replacement feed, but it is not a complete replacement for tool or template discovery.
* There is no apparent alternate-source option for `dotnet new search`.

### Environment

```console
.NET SDK:
Version: 11.0.100-preview.7.26381.103
Commit: e2c1e00b3d
MSBuild version: 18.10.0-1.26381.103+e2c1e00b3

Runtime Environment:
OS Name: Mac OS X
OS Version: 26.6
OS Platform: Darwin
RID: osx-arm64

Host:
Version: 11.0.0-preview.7.26381.103
Architecture: arm64
```

Start by reproducing the configured-source scenarios with `dotnet tool search` and `dotnet new search`, then locate the CLI entry points for those commands. Compare their source selection with `dotnet package search` and the NuGet configuration behavior. Done means both searches honor enabled replacement feeds or provide a source override, and failed tool searches return a nonzero exit code.

Written by the indexing model from the issue text.