libmscordaccore.so null pointer dereference in DBI-Callback thread on x64 Linux (.NET 9, all patches)

### Description

Symptom:

When debugging a .NET 9 console application under coreclr (vsdbg) that loads a large number of assemblies at runtime (~316 managed assemblies + many native .so libraries via a third-party SDK), the debug session ends silently. No error is shown in VS Code, no terminated or exited event is fired, and managed breakpoints are never hit. The target process itself continues running normally.

sudo dmesg reveals vsdbg's own DBI-Callback thread crashing with a null pointer dereference inside libmscordaccore.so:

```
[ 778.946248] DBI-Callback[10410]: segfault at 0 ip 00007bcc8ce067b5 sp 00007bcc8cbfc940 error 4 in libmscordaccore.so[2057b5,7bcc8ccae000+1a5000] likely on CPU 9 (core 9, socket 0)
[ 778.946259] Code: 0a e4 ff 48 63 0c 8a 48 01 d1 ff e1 4c 8b 6d d0 49 8b bd 98 00 00 00 48 89 7d a0 be 08 00 00 00 ba 01 00 00 00 e8 6b 96 f2 ff <48> 8b 00 49 89 44 dd 78 48 8b 45 c8 48 85 c0 74 0c 48 8b 4d a0 48
[ 1993.518127] DBI-Callback[18733]: segfault at 0 ip 00007acf156067b5 sp 00007acf153fc940 error 4 in libmscordaccore.so[2057b5,7acf154ae000+1a5000] likely on CPU 9 (core 9, socket 0)
[ 1993.518136] Code: 0a e4 ff 48 63 0c 8a 48 01 d1 ff e1 4c 8b 6d d0 49 8b bd 98 00 00 00 48 89 7d a0 be 08 00 00 00 ba 01 00 00 00 e8 6b 96 f2 ff <48> 8b 00 49 89 44 dd 78 48 8b 45 c8 48 85 c0 74 0c 48 8b 4d a0 48
[ 2021.466030] DBI-Callback[19191]: segfault at 0 ip 000072f9e04067b5 sp 000072f9c6ffa940 error 4 in libmscordaccore.so[2057b5,72f9e02ae000+1a5000] likely on CPU 8 (core 8, socket 0)
[ 2021.466041] Code: 0a e4 ff 48 63 0c 8a 48 01 d1 ff e1 4c 8b 6d d0 49 8b bd 98 00 00 00 48 89 7d a0 be 08 00 00 00 ba 01 00 00 00 e8 6b 96 f2 ff <48> 8b 00 49 89 44 dd 78 48 8b 45 c8 48 85 c0 74 0c 48 8b 4d a0 48
```

Key observations:

- segfault at 0 — null pointer dereference
- Faulting instruction at <> marker: 48 8b 00 = MOV RAX, [RAX] — reading through a null pointer in RAX
- error 4 — page fault on read, user space
- The faulting thread is DBI-Callback — vsdbg's own Data Access Component callback thread, not the target application
- All three crashes are at the same offset (2057b5) with byte-for-byte identical faulting code — the crash is 100% deterministic
- Three separate debug sessions crashed: two with justMyCode: true, one with justMyCode: false — the setting has no effect
- Also reproduced with .NET 9.0.1, where the offset was 2056d5 — same logical code path, shifted slightly between patch versions

Configuration settings that do not affect the crash:

- justMyCode: true vs justMyCode: false — identical crash in both cases
- enableStepFiltering: false — no effect
- DOTNET_DbgEnableMiniDump: "0" — no effect

Not reproducible:
While I can reproduce this on x86_64 systems (different Ubuntu versions, hardware configurations) with my application, I cannot submit a reproducible example.

- "type": "lldb" on the same binary — works correctly
- linux-arm64 with arm64 vsdbg and arm64 .NET 9 runtime — works correctly

### Reproduction Steps

Attempted minimal reproductions (not successful):

The following standalone programs were tested under coreclr debugging on x64 Linux and did not reproduce the crash:

- Dynamic assemblies via AssemblyBuilder — 1306 assemblies created and loaded, debug session completed normally
- Assembly.LoadFrom scanning dotnet — 1879 assemblies attempted (many with load errors), debug session completed normally
- Assembly.LoadFrom scanning the application's own output directory — 316 assemblies loaded, debug session completed normally

This indicates the crash is not triggered by assembly count alone. The trigger appears to be specific to the metadata structure or type of assemblies loaded by the third-party SDK. A simple count simulation is insufficient to reproduce it.

### Expected behavior

vsdbg does not crash on x86_64 systems

### Actual behavior

vsdbg crashes on x86_64 systems

### Regression?

This same behavior has existed for at least two or three years with my application, and it is why I primarily use Ubuntu on arm64, because I can effectively use vsdbg.

### Known Workarounds

Use lldb-based debugging ("type": "lldb" in VS Code launch config) instead of coreclr on x64 Linux. Alternatively, debug on a linux-arm64 machine where both coreclr and lldb work correctly with the same application and same vsdbg version.

### Configuration

Environment:

- OS: Ubuntu Linux 24.04 x86_64
- .NET SDK: 9.0.102
- .NET Runtimes tested: 9.0.1, 9.0.2, 9.0.3 (all affected)
- Debugger: vsdbg via ms-dotnettools.csharp 2.130.5 (linux-x64)
- Not reproducible on: linux-arm64 (same vsdbg version, same application)

### Other information

_No response_