NuGet - Dependabot fails to update projects that reference .esproj projects.

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Package ecosystem

NuGet

### Summary
Dependabot incorrectly detects additional target frameworks (`net6.0`) when a .NET SDK-style project references a non-.NET `.esproj` project (`Microsoft.VisualStudio.JavaScript.Sdk`). This causes package compatibility evaluation to fail for packages that are valid for the actual declared target framework (e.g., `net10.0`).

### Repository Structure
- **Backend.API**
- SDK: `Microsoft.NET.Sdk.Web`
- `net10.0`
- Uses Central Package Management (`Directory.Packages.props`)
- Contains `ProjectReference` to:
```
..\Frontend.UI\Frontend.UI.esproj
```

- **Frontend.UI**
- SDK: `Microsoft.VisualStudio.JavaScript.Sdk`
- No ``
- Pure JavaScript frontend project

### Observed Behaviour
During dependency discovery, Dependabot reports:

```json
"TargetFrameworks": [
"net10.0",
"net6.0"
],
"ReferencedProjectPaths": [
"../Frontend.UI/Frontend.UI.esproj"
],
```

Even though the API project only declares:

```xml
net10.0
```

Because `net6.0` is included in the evaluated framework list, Dependabot attempts to validate package compatibility against both `net10.0` and `net6.0`.

This results in failures such as:

```
NU1202: Package X.Y.Z 1.2.3 is not compatible with net6.0
```

Dependabot then refuses to update the dependency due to perceived incompatibility.

### Key Detail
The issue only occurs when the `.esproj` `ProjectReference` is present.

If the following block is removed from the `Backend.API.csproj` file:

```xml

false

```

Dependabot correctly evaluates the project as targeting only `net10.0`, and updates proceed normally.

### Suspected Root Cause
When encountering a non-.NET SDK project reference (`.esproj`), Dependabot:

- Falls back to a legacy package reference resolution mode
```
updater | INFO Project /home/dependabot/dependabot-updater/repo/Frontend.UI/Frontend.UI.esproj is legacy
updater | INFO ...and setting manual package resolution to true
```
- Synthesizes a temporary project for analysis
```
updater INFO Performing single restore for project /tmp/legacy-package-reference-resolution_ObsuKA/Project.csproj
```
- Defaults that synthetic project to `net6.0`
- Includes `net6.0` in the union of evaluated target frameworks

This causes false incompatibility results.

### Expected Behaviour
Dependabot should:

- Ignore non-.NET project references when evaluating target frameworks
**or**
- Only use the explicitly declared `` of the .NET SDK project
**or**
- Avoid injecting default frameworks (e.g., `net6.0`) during dependency analysis

A `.esproj` should not introduce additional target frameworks into dependency compatibility evaluation.

### Impact
- Blocks dependency updates
- Produces false NU1202 compatibility failures
- Affects projects that combine:
- ASP.NET backend
- JavaScript frontend using `.esproj`
- Central Package Management

### Reproduction Steps
1. Create an SDK-style .NET Web project targeting `net10.0`
2. Enable Central Package Management
3. Add a `ProjectReference` to a `.esproj` using `Microsoft.VisualStudio.JavaScript.Sdk`
4. Run Dependabot NuGet update
5. Observe additional `net6.0` framework in discovery output and compatibility failures

Reproduce the discovery using Backend.API.csproj, Frontend.UI.esproj, and Directory.Packages.props, then inspect the reported target frameworks and legacy package-resolution logs. Done means the referenced .esproj no longer adds net6.0, only the declared net10.0 is evaluated, and the NuGet update no longer fails with the reported compatibility error.

Written by the indexing model from the issue text.