Performance regression upgrading from 10.0.100 -> 10.0.300

### Describe the bug

We have multiple WPF desktop apps running on .NET 10 self contained, compiled with ReadyToRun (R2R) and distributed as MSIX packages.

We run automated performance-monitoring tests that measure app startup time for every build. After upgrading our SDK to 10.0.300, these tests detected a startup-time regression of roughly 100 ms (~10%) across our apps. In the chart below, each colored line is a different application:

Some details on what we observed:

- Reverting to 10.0.100 restored the faster startup times — the regression tracks the SDK/runtime version, not our code.
- I then tried the latest 10.0.301, and the startup times jumped again, so the regression is still present in the newest servicing release.
- We have not yet profiled the apps, so I can't point to exactly where the extra time is spent — but it is consistently ~100 ms, which is ~10% of our startup time.

This really hurts us, because we invest a huge amount of effort into reducing the already-slow startup of .NET WPF apps, and this upgrade wiped out a meaningful chunk of those gains. I'm hoping this gets attention.

### Minimal reproduction

I built a minimal reproduction to quantify this. Two trivial WPF apps (App1 = empty window, App2 = window with menu/toolbar/DataGrid), published self-contained + ReadyToRun (win-x64) so the runtime is pinned to the SDK rather than to whatever shared runtime is installed.

Measurement: each app records DateTime.Now − Process.StartTime at its ContentRendered event (first rendered frame) and appends it to a CSV. 30 measured launches per configuration, 3 warmups discarded, and the four configs are interleaved (100/300/100/300…) so any background/thermal drift hits all of them equally. Medians are used to reject outliers.

The only variable changed is the SDK, which determines the bundled runtime:

Bundled runtime per SDK:

| SDK | Bundled WPF / CLR |
| -------- | ------------------------------------------------ |
| 10.0.100 | `PresentationCore 10.0.0-rtm` + `coreclr 10.0.0` |
| 10.0.300 | `PresentationCore 10.0.8-servicing` + `coreclr 10.0.8` |

Startup time — median of 30 runs (ms):

| App | 10.0.100 | 10.0.300 | Delta |
| ------------------------------ | -------- | -------- | --------------- |
| App1 (empty window) | 538.9 | 589.7 | +50.8 (+9.4%) |
| App2 (menu/toolbar/DataGrid) | 626.3 | 716.7 | +90.4 (+14.4%) |

Full stats — median / mean / min / max (ms):

| App | SDK | Median | Mean | Min | Max |
| ---- | -------- | ------ | ----- | ----- | ----- |
| App1 | 10.0.100 | 538.9 | 549.2 | 518.9 | 611.0 |
| App1 | 10.0.300 | 589.7 | 593.0 | 567.0 | 643.1 |
| App2 | 10.0.100 | 626.3 | 633.5 | 592.7 | 695.9 |
| App2 | 10.0.300 | 716.7 | 718.9 | 671.1 | 817.2 |

Key takeaway: the regression reproduces on an empty WPF window (App1), so this is in the framework/runtime, not application code. Moving from the 10.0.0 RTM runtime to the 10.0.8 servicing runtime costs ~50–90 ms (9–14%) of startup, which matches the ~100 ms / ~10% regression I originally reported across our production apps. The heavier app pays more in absolute terms.

[WpfStartupBench_repro.zip](https://github.com/user-attachments/files/29496646/WpfStartupBench_repro.zip)

### Is this a regression?

yes

### Are there any workarounds?

no

Start with WpfStartupBench_repro.zip and run the two self-contained, ReadyToRun WPF apps under SDKs 10.0.100 and 10.0.300, using the documented interleaved launches and median measurements. Compare the empty-window and menu/toolbar/DataGrid results, then profile startup to locate the servicing-runtime regression. Done means identifying the responsible framework or runtime area and confirming the startup difference is addressed.

Written by the indexing model from the issue text.