dotnet ef dbcontext optimize --precompile-queries does not pass $(Configuration) to MSBuildWorkspace, breaking non-default build configurations

### Environment

- .NET SDK: 11.0.100-rc.1.26425.128
- Also reproduces on .NET 10 SDKs with EF Core 10.0.12
- EF Core: 10.0.12 and 11.0.0-rc.1.26425.128
- OS: macOS arm64
- This appears to be MSBuild/Roslyn-level behavior and not OS-specific

### Reproduction

A minimal project uses a non-default `$(Configuration)` name with Configuration-conditional `TargetFramework` and `PackageReference` values.

For example:

```xml
net10.0

Debug Custom;Release Custom

net11.0

```

EF Core package references are conditioned on the resulting target framework.

Run:

```bash
dotnet publish MyProj.csproj --configuration "Release Custom"
```

The normal build succeeds correctly under `Release Custom`, producing the expected `net11.0` output with the correct EF Core version.

The `OptimizeDbContext` task then invokes:

```text
dotnet ef dbcontext optimize --precompile-queries --nativeaot
```

against the already-built application.

That query-precompilation step fails with errors such as:

```text
error CS0234: The type or namespace name 'EntityFrameworkCore' does not exist in the namespace 'Microsoft'

error CS0246: The type or namespace name 'DbContext' could not be found
```

followed by cascading resolution errors across the project.

### Expected behavior

The project reopened by `MSBuildWorkspace` during query precompilation should be evaluated with the same relevant MSBuild global properties as the build that invoked `OptimizeDbContext`.

At minimum, the active `$(Configuration)` should be preserved.

### Actual behavior

`DbContextOperations.PrecompileQueries` creates the workspace with only:

```csharp
workspace = MSBuildWorkspace.Create(
new Dictionary
{
["_EFGenerationStage"] = "build"
});
```

There is also an adjacent:

```text
// TODO: pass through properties
```

comment.

`OpenProjectAsync` then re-evaluates the actual `.csproj`, but without the active Configuration.

For projects whose target framework, package references, project references, or other build properties depend on `$(Configuration)`, that re-evaluation can resolve an entirely different project graph than the build currently in progress.

In the minimal repro, the workspace falls back to the project's unconditional/default target framework and package set rather than the `Release Custom` graph that was successfully built moments earlier.

The generated-query compilation therefore cannot resolve the application's EF Core references and fails.

### Root cause

The issue appears to originate in:

`src/EFCore.Design/Design/Internal/DbContextOperations.cs`

inside `PrecompileQueries`, specifically the `MSBuildWorkspace.Create(...)` call.

The relevant implementation, including the `// TODO: pass through properties` comment, is unchanged in:

- EF Core 10.0.12
- EF Core 11.0.0-rc.1.26425.128

### Impact

This blocks Native AOT / precompiled-query publishing for projects using legitimate non-default build configuration names or Configuration-conditioned dependencies.

This is not provider-specific.

I encountered it while enabling EF Core 11 Native AOT support for a third-party provider which intentionally maintains separate builds using:

```text
Debug EF10
Release EF10
Debug EF11
Release EF11
```

The same problem was then reproduced in a standalone project with no third-party provider code.

### Minimal repro

The repro consists of a single project and `Program.cs`. Two variants were tested:

- EF Core 11 RC1 with an unconditional net10.0 default overridden to net11.0 by `Release Custom`
- EF Core 10.0.12 with the target frameworks reversed

Both reproduce the same failure.

The query-free DbContext is intentional so that this issue remains isolated from unrelated query-translation/precompilation behavior.

I can provide the minimal repro if useful.

### Versions

Confirmed affected:

- Microsoft.EntityFrameworkCore.Design / Tasks 10.0.12
- Microsoft.EntityFrameworkCore.Design / Tasks 11.0.0-rc.1.26425.128

### Possibly related

#36055 hits the same `DbContextOperations.PrecompileQueries` → `MSBuildWorkspace.OpenProjectAsync` code path with a different proximate symptom ("The build host could not be found"). Flagging in case the two share a root cause in how `MSBuildWorkspace` is used here, though the specific defect described above (missing `Configuration` passthrough) is distinct from that report.