dotnet publish crashes (SIGBUS) when PublishSingleFile=true on Linux

### Describe the bug
`dotnet publish` crashes with `SIGBUS` (Bus error) on Linux during the `GenerateSingleFileBundle` step whenever `PublishSingleFile=true` is used.

This reproduces even with a brand new minimal console project (`dotnet new console`), so it does not appear to be project-specific.

Dump analysis shows the failing thread inside `Microsoft.NET.HostModel.Bundle.Bundler.AddToBundle(...)` while writing via `System.IO.UnmanagedMemoryStream.Write`, failing in `System.Buffer.MemmoveInternal` (native crash -> SIGBUS).

### To Reproduce
Environment: .NET SDK 10.0.102, linux-x64, running inside Docker.

1. Create a minimal repro:
```bash
mkdir repro && cd repro
dotnet new console
```

2. Publish as single-file:
```bash
dotnet publish ./repro.csproj -r linux-x64 -c Release \
-p:PublishSingleFile=true \
-o ./publish
```

Observed result:
- Publish reaches `GenerateSingleFileBundle`, then `dotnet` terminates with `Bus error (core dumped)` / `SIGBUS`.
- A core dump can be captured; the crashing thread is inside the single-file bundler.

Expected result:
- Publish completes successfully and produces a runnable single-file output.

Also reproduced with additional publish properties (still crashes as long as `PublishSingleFile=true`):
```bash
dotnet publish ./repro.csproj -r linux-x64 -c Release \
-p:PublishSingleFile=true \
-p:EnableCompressionInSingleFile=true \
-p:SelfContained=true \
-o ./publish
```

### Exceptions (if any)
Console output (trimmed):
```text
... GenerateSingleFileBundle ...
[createdump] Crashing thread ... signal 7 (0007)
Bus error (core dumped)
```

Managed stack from the crashing thread (from dump analysis, trimmed):
```text
System.Buffer.MemmoveInternal
System.IO.UnmanagedMemoryStream.Write
Microsoft.NET.HostModel.Bundle.Bundler.AddToBundle(...)
Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(...)
Microsoft.NET.Build.Tasks.GenerateBundle.ExecuteCore()
...
```

### Further technical details
details of dotnet --info

```text
.NET SDK:
Version: 10.0.102
Commit: 4452502459
MSBuild version: 18.0.7+445250245

Runtime Environment:
OS Platform: Linux
RID: linux-x64

Host:
Version: 10.0.2
Architecture: x64
Commit: 4452502459

Environment variables:
DOTNET_RUNNING_IN_CONTAINER [true]
DOTNET_SDK_VERSION [10.0.102]
DOTNET_VERSION [10.0.2]
```

- IDE: N/A (command line)
- Host OS (Docker host): CentOS Linux 7 (Core)
- Docker / container runtime:
- Docker Engine 20.10.22
- containerd 1.6.15
- runc 1.1.4
- Disk / filesystem notes:
- Plenty of free disk space available (not an ENOSPC situation).
- Container root filesystem is overlayfs (Docker overlay2).
- The publish output directory used in tests is on an `xfs` mount (inside the container).
- Additional diagnostics:
- Core dumps are available; I can provide additional signal info / native backtrace / dump privately if needed.

- Container image:
- `mcr.microsoft.com/dotnet/sdk:10.0` (reproduces inside this official image)
- Note: This reproduces on my Docker host (CentOS 7 + Docker 20.10.22). Not sure if host kernel / storage driver is required to reproduce.

(Question) Could this be related to mmap/UnmanagedMemoryStream usage in the single-file bundler on certain kernel / overlay2 / xfs combinations? I can help test any suggested workarounds or provide additional diagnostics if needed.