Single-file apps die with "Arithmetic overflow while reading bundle" when started with the dynamic linker (`/proc/self/exe` points to ld.so)

### Description

In order to make a dynamic binary truly portable on linux (no dependency to the host userland) it has to be launched via bundled dynamic linker:

```
/path/to/bundled/ld-linux-x86-64.so.2 --library-path ./app
```

This works for basically every dynamically linked ELF out there, but with .NET single-file executables when the binary is launched this way it crashes before with:

```
Failure processing application bundle; possible file corruption.
Arithmetic overflow while reading bundle.
A fatal error occurred while processing application bundle
```

The reason is that the single-file host locates its own file through `/proc/self/exe` to find the bundle header offset. When the process is started via the dynamic linker, `/proc/self/exe` is `ld-linux-x86-64.so.2` or the sharun wrapper and not the app. The binary then tries to extract the payload from that and dies with the message above.

This problem also breaks binaries on systems without `/proc` or if the binary only has executable permissions (`111`).

### Reproduction Steps

Any app published with -p:PublishSingleFile=true shows this:

```
dotnet new console -o hello && cd hello
dotnet publish -p:PublishSingleFile=true --self-contained -r linux-x64
/lib64/ld-linux-x86-64.so.2 ./bin/Release/*/linux-x64/publish/hello
```

### Expected behavior

The binary should just work.

### Actual behavior

```
/lib64/ld-linux-x86-64.so.2 ./bin/Release/*/linux-x64/publish/hello
Failure processing application bundle; possible file corruption.
Arithmetic overflow while reading bundle.
A fatal error occurred while processing application bundle
```

### Regression?

_No response_

### Known Workarounds

This is a problem that also affected bun:

* https://github.com/oven-sh/bun/issues/28281
* https://github.com/oven-sh/bun/issues/34173

And was fixed by https://github.com/oven-sh/bun/pull/26923

### Configuration

_No response_

### Other information

_No response_

No source files or tests are named. Start by reproducing the failure with the provided dotnet publish command and bundled dynamic linker invocation, then trace the single-file host's bundle-location handling when /proc/self/exe is not the application. Done means the published executable starts successfully in this launch mode without the arithmetic-overflow error.

Written by the indexing model from the issue text.