Clean dotnet build causes XamlCompiler failure (msbuild works)

### Describe the bug

This repro shows a WinUI XAML compiler inconsistency for a `ResourceDictionary` with `x:Class` that contains a `ControlTemplate` using `x:Bind` against a named element's `Visibility` property.

From a **clean** project state, the same project:

- **fails** with `dotnet build -c Release`
- **succeeds** with Visual Studio's `MSBuild.exe` in Release

After a successful `MSBuild.exe` build, a subsequent `dotnet build -c Release` can also succeed without cleaning, so the repro appears to depend on the initial clean build path / generated artifacts.

The failing build exits from `XamlCompiler.exe` with only:

```text
error MSB3073: The command "...\\XamlCompiler.exe" "obj\\Release\\net8.0-windows10.0.19041.0\\input.json" "obj\\Release\\net8.0-windows10.0.19041.0\\output.json" exited with code 1.
```

### Why is this important?

Can't do clean CLI builds from commandline - Developer works in Visual Studio and don't see an issue, checks things in and then breaks CLI build.

### Steps to reproduce the bug

Unzip repro: [Repro.WinUI.zip](https://github.com/user-attachments/files/29156419/Repro.WinUI.zip)

1. Delete `bin` and `obj` under `Repro.WinUI` if they exist.
2. Run:

```powershell
dotnet build E:\apps300\output\winui-xbind-repro\Repro.WinUI\Repro.WinUI.csproj -c Release -v:minimal
```

3. Observe build failure from `XamlCompiler.exe`.
4. Run:

```powershell
"C:\Program Files\Microsoft Visual Studio\18\Enterprise\MSBuild\Current\Bin\MSBuild.exe" `
Repro.WinUI\Repro.WinUI.csproj `
/restore /t:Build /p:Configuration=Release /v:minimal /nologo
```

5. Observe that the project builds successfully with Visual Studio MSBuild.
6. Run `dotnet build` again without cleaning:

```powershell
dotnet build Repro.WinUI\Repro.WinUI.csproj -c Release -v:minimal
```

7. Observe that this second `dotnet build` may now succeed.

### Actual behavior

- A **clean** `dotnet build` fails in WinUI XAML pass 2 with only `MSB3073` / `XamlCompiler.exe exited with code 1`
- Visual Studio `MSBuild.exe` builds the same project successfully
- After the successful MSBuild build, a later incremental `dotnet build` can succeed

### Expected behavior

Both build paths should behave the same from a clean state. Either both should compile successfully or both should report a concrete XAML diagnostic.

### Screenshots

_No response_

### NuGet package version

At least 1.8+

### Windows version

Windows 11 (24H2): Build 26100

### Additional context

## Workaround

Replacing the `x:Bind` element-to-element expressions with standard `Binding` + `ElementName` avoids the failure:

```xml

```

## Latest package check

This was also tested against the latest stable `Microsoft.WindowsAppSDK.WinUI` package available at the time of writing:

- `2.2.1`

Result:

- clean `dotnet build -c Release` still fails
- Visual Studio `MSBuild.exe` still succeeds
- replacing the two `x:Bind` expressions with `Binding` + `ElementName` still makes the clean CLI build succeed

With `2.2.1`, the clean CLI failure surfaced as:

```text
Xaml Internal Error error WMC9999: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "Microsoft.UI.Xaml.Markup.Compiler.ErrorMessages.resources" was correctly embedded or linked into assembly "XamlCompiler" at compile time, or that all the satellite assemblies required are loadable and fully signed.
```

So the latest package tested did **not** eliminate the issue; it changed the observable failure mode.

## Environment

- OS: Windows 11, `10.0.26200`
- .NET SDK: `10.0.300`
- `dotnet build` MSBuild runtime: `Core`
- Visual Studio MSBuild runtime: `Full`
- Visual Studio: `18 Enterprise`
- WinUI package originally reproduced with: `Microsoft.WindowsAppSDK.WinUI 1.8.250906003`
- Latest stable package additionally tested: `Microsoft.WindowsAppSDK.WinUI 2.2.1`
- Target framework: `net8.0-windows10.0.19041.0`

## Notes

- This repro is intentionally a **class library** because the original failure was in a WinUI library project rather than a full app.
- The issue appears to be tied to **XAML compilation**, not runtime behavior.
- The behavior is **clean-build sensitive**: a successful Visual Studio `MSBuild.exe` build seems to leave generated artifacts/state that let later `dotnet build` runs succeed.
- A better failure mode would be a concrete page-level XAML error instead of a silent `XamlCompiler.exe` exit code.

Start with the attached Repro.WinUI.zip, delete bin and obj, and compare the clean dotnet build with the Visual Studio MSBuild command. Examine the mentioned input.json and output.json around the XamlCompiler.exe failure and the differing diagnostics. Done means both clean build paths behave consistently or report a concrete XAML diagnostic.

Written by the indexing model from the issue text.