WPF Temporary Project Caches Stale Type Metadata, Making Project Unbuildable

### Description

# WPF Temporary Project Caches Stale Type Metadata, Making Project Unbuildable

## Summary
WPF's temporary assembly generation (`*_wpftmp.csproj`) caches type metadata that becomes permanently stale when properties are added to existing classes. The cache survives all standard clearing operations, system restarts, and even property renaming, making the project completely unbuildable. No documented method exists to clear this cache.

## Environment
- **Visual Studio:** 2022 Community (17.0)
- **.NET SDK:** 8.0.306
- **Target Framework:** net8.0-windows
- **Project Type:** WPF + Windows Forms hybrid using `Microsoft.NET.Sdk`
- **Compiler:** Roslyn 4.14.0-3.25412.6
- **OS:** Windows 11

## What Makes This Critical

### The Cache is Indestructible
We attempted **every documented cache-clearing method** with no success:

**Standard Operations (All Failed):**
- `dotnet clean`
- Manual deletion of `bin/` and `obj/` folders
- Deleted all `*_wpftmp*` directories
- Killed all MSBuild and devenv processes
- Full system restart

**Advanced Cache Clearing (All Failed):**
- Deleted `C:\Users\\AppData\Local\Temp\Roslyn\`
- Deleted `C:\Users\\AppData\Local\Temp\MSBuildTemp\`
- Deleted `C:\Users\\AppData\Local\Microsoft\VisualStudio\17.0_*\Roslyn\` (entire folder)
- Deleted `C:\Users\\AppData\Local\Microsoft\VisualStudio\17.0_*\Designer\Cache\`
- Deleted `C:\Users\\AppData\Local\Microsoft\VisualStudio\17.0_*\ComponentModelCache\`
- Deleted solution `.vs` folder
- Ran `dotnet nuget locals all --clear`

**Workarounds Attempted (All Failed):**
- Renamed property from `ToolResults` to `Results` (cache rejected BOTH names)
- Incremented assembly version to 2.0.0.0
- Deleted and recreated the source file
- Updated file timestamps
- Set `false` (broke XAML compilation)
- Created separate class library project (cache still used old definition)
- Excluded files from compilation

### The Cache is Adaptive
When we renamed the property to work around the cache, **the cache learned the new name and rejected it too**. This suggests the cache is actively comparing against a stored snapshot rather than just missing an update.

## Impact
**This bug makes WPF projects completely unbuildable** when certain type changes occur. The only known solutions are:
1. Complete reinstall of Visual Studio + .NET SDK
2. Build on a different computer
3. Wait for cache to expire naturally (timeframe unknown)
4. Keep new functionality permanently disabled

## Root Cause Analysis
The WPF temporary project generation system (`GenerateTemporaryTargetAssembly` target) creates a temporary `.csproj` file during `CoreCompile` for XAML type resolution. This process caches type metadata in an **undocumented location** that:
- Survives all standard cache-clearing operations
- Survives system restarts
- Survives file deletion and recreation
- Survives assembly version changes
- Is not cleared by any documented MSBuild or Roslyn cache-clearing method

## Evidence
From detailed MSBuild output, we confirmed:
- `Models\AIResponseChunk.cs` **is included** in the main project compile list
- The source file **contains the property** (verified via file inspection)
- Visual Studio IntelliSense **recognizes the property**
- The WPF temp project (`Redline_xxxxx_wpftmp.csproj`) **fails to recognize it**

## Request
1. **Document the cache location** so developers can clear it manually
2. **Provide a reliable cache-clearing mechanism** (e.g., MSBuild property or command)
3. **Fix the cache invalidation logic** to detect type changes
4. **Add cache expiration** to prevent permanent staleness

## Additional Context
- This appears to affect recently added properties specifically - older properties in the same class work fine
- The issue may be related to Roslyn's type metadata caching interacting with WPF's temporary assembly generation
- Similar issues reported in .NET 8 WPF projects but no documented resolution
- The cache appears to store complete type snapshots rather than incremental changes

## Workaround That Should Work (But Doesn't)
According to community suggestions, moving the affected classes to a separate class library should bypass the cache since the temp project would reference the compiled DLL. **This did not work** - the cache still used the old type definition even when referencing an external assembly.

This is a critical bug that needs urgent attention as it makes WPF development unreliable and unpredictable.

### Reproduction Steps

1. Create a .NET 8 WPF project with a model class:
```csharp
namespace Redline.Models
{
public class AIResponseChunk
{
public string? Text { get; set; }
public List? ToolCalls { get; set; }
public bool IsComplete { get; set; }
}
}
```

2. Build the project successfully
3. Add a new property to the class:
```csharp
public List? ToolResults { get; set; }
```

4. Reference the new property in code:
```csharp
yield return new AIResponseChunk
{
ToolResults = savedToolResults,
IsComplete = false
};
```

5. Attempt to build

### Expected behavior

Project should build successfully with the new property recognized.

### Actual behavior

Build fails with errors from WPF temporary project:
```
error CS0117: 'AIResponseChunk' does not contain a definition for 'ToolResults'
error CS1061: 'AIResponseChunk' does not contain a definition for 'ToolResults' and no accessible extension method...
```

The property **exists** in the source file and is visible in Visual Studio IntelliSense, but the WPF temporary project (`Redline_xxxxx_wpftmp.csproj`) uses a cached version without the new property.

### Regression?

_No response_

### Known Workarounds

_No response_

### Impact

_No response_

### Configuration

_No response_

### Other information

_No response_