Single-file publish to a UNC share is ~10x slower on SDK 10 than on SDK 9

### Describe the bug

Publishing a framework-dependent, single-file, ReadyToRun app **directly to a UNC path** (`PublishDir` pointing at a network share) went from well under a minute to several minutes after upgrading the SDK from 9.0.3xx to 10.0.400.

The regression is caused by the **SDK**, not by the target framework: keeping the source and `TargetFramework` at `net9.0` and changing only the SDK reproduces the slowdown. Publishing the same projects to a **local** directory is fast on both SDKs (1-2 s), so the cost is specific to writing the bundle over SMB.

Removing `PublishSingleFile` makes the publish fast again on SDK 10, which points at the single-file bundling step rather than at the plain file copy.

### Steps to reproduce

1. `dotnet new console -f net9.0`, add `` (any dependency set large enough to produce a \~30 MB bundle).
2. Publish to a UNC share:

```
dotnet publish -c Release -r win-x64 --self-contained false \\
-p:PublishSingleFile=true -p:PublishReadyToRun=true \\
-p:PublishDir=//SERVER/share/somefolder
```

3. Run the same command with the .NET 9 SDK and with the .NET 10 SDK, each into a fresh empty destination folder, and compare wall-clock time.

### Expected behavior

Publish time to a UNC share on SDK 10 comparable to SDK 9.

### Actual behavior

SDK 10 is roughly an order of magnitude slower.

## Measurements

**Minimal repro** — `dotnet new console -f net9.0` plus a single `PackageReference` (EF Core SqlServer 9.0.10), producing a 28.7 MB bundle. Identical sources and `TargetFramework`; the only variable is the SDK. Local runs are cold (restore + build + R2R included); UNC runs are warm, so they isolate the publish/bundle step.

|SDK|`PublishDir`|Wall clock|
|-|-|-|
|9.0.317|local|32 s|
|10.0.400|local|33 s|
|9.0.317|UNC|**30 s**|
|10.0.400|UNC|**422 s**|

**Real application** — console app, \~30-35 MB bundle, same publish settings:

|SDK|TFM|local|UNC|
|-|-|-|-|
|9.0.317|net9.0|\~1 s|**38 s**|
|10.0.400|net9.0|\~2 s|**440 s**|
|10.0.400|net10.0|\~1 s|**412 s**|

Note that SDK 10 with `net9.0` (440 s) and with `net10.0` (412 s) are equally slow, while SDK 9 with the same `net9.0` sources takes 38 s. Local publishes are unaffected on both SDKs.

## Notes

Each timed run targeted a fresh, empty destination directory, and the presence and size of the produced `.exe` was verified after every run. Local publishes were warmed up first (restore + build + R2R already done), so the reported times isolate the publish/bundle step.

### Is this a regression?

Yes. The same publish is fast on SDK 9.0.317 and slow on SDK 10.0.400.

The regression is attributable to the SDK alone: with identical sources and
TargetFramework (net9.0), switching only the SDK takes the publish from 30 s
to 422 s. Publishing to a local directory is unaffected on both SDKs (32 s vs
33 s), so only the write to the UNC share regressed.

Last known good: 9.0.317
First known bad: 10.0.400

I have not bisected the intermediate 10.0.1xx/2xx/3xx feature bands, so the
exact release that introduced it is unknown; those two are simply the versions
I had available side by side.

### Are there any workarounds?

Publish to a local staging directory and copy the result to the share afterwards, e.g. in the publish profile:

```xml
C:\staging\MyApp\
\\SERVER\share\MyApp\

```

This brings the end-to-end publish back to ~20 s.

### dotnet --info output

```console
.NET SDK:
Version: 10.0.400
Commit: 14fbf8d527
Workload version: 10.0.400-manifests.b0ae88bd
MSBuild version: 18.9.6+14fbf8d52

Ambiente di runtime:
OS Name: Windows
OS Version: 10.0.26200
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.400\

Carichi di lavoro .NET installati:
Non sono presenti carichi di lavoro installati da visualizzare.
Configurato per l'uso "workload sets" durante l'installazione di nuovi manifesti.
Non sono installati set di carico di lavoro. Esegui il "dotnet workload restore" per installare un set del carico di lavoro.

Host:
Version: 10.0.11
Architecture: x64
Commit: e2f47b0110

.NET SDKs installed:
10.0.400 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.19 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download
```

### IDE version

Visual Studio 2026 Enterprise - v18.9.2

### Other details

## Environment

* Windows 11 Enterprise 10.0.26200, x64
* SDKs: 9.0.317 and 10.0.400 (side-by-side; the 9.0.317 SDK installed via `dotnet-install.ps1` into a private directory)
* Destination: SMB share on a Windows server, reached over the corporate LAN
* Publish settings: `Release`, `win-x64`, `SelfContained=false`, `PublishSingleFile=true`, `PublishReadyToRun=true`

Start by reproducing the issue with the documented dotnet publish commands, comparing SDK 9.0.317 and 10.0.400 on local and UNC destinations. Trace the SDK's single-file publish and bundling path to identify the UNC-specific regression; done means SDK 10 publish time is comparable to SDK 9 without slowing local publishing.

Written by the indexing model from the issue text.