Legacy DAC SyncBlock data is unavailable for macOS x64 .NET 11 dumps

### Description

When a macOS x64 .NET 11 dump is analyzed with `dotnet-dump` and the matching legacy DAC, SyncBlock data is unavailable. This causes two deterministic SOS failures against the same capture-family dump.

`syncblk` fails instead of listing an intentionally inflated, held monitor:

```text
> syncblk
Error requesting SyncBlk data
```

`verifyheap` consequently reports apparent heap corruption for an object whose SyncBlock cannot be found:

```text
Segment Object Failure Reason
00058acda2d0 00018c4052f8 SyncBlockMismatch Object 18c4052f8 System.Object had a SyncBlock index of 1 but the runtime has no matching SyncBlock
1,154 objects verified, 1 error.
```

Expected behavior:

- `syncblk` lists the held SyncBlock with `MonitorHeld > 0`.
- `verifyheap` reports `0 errors` and `No heap corruption detected`.

Minimal replay:

```text
dotnet-dump analyze heap.dmp
> runtimes --usecdac false --DacSignatureVerification false
> syncblk
> verifyheap
```

The failures reproduce in both Debug and Release SOS.Tests runs. Corresponding cDAC and LLDB configurations pass against the identical capture-family dump. The exact legacy-DAC `dotnet-dump` configurations also pass on Ubuntu, indicating that capture/transfer corruption is not involved and that this is macOS-specific.

### Configuration

- Tool: `dotnet-dump`
- Host: macOS 15 x64 (`osx.15.amd64.open`)
- Target runtime: .NET `11.0.26.42702`; product layout `11.0.0-rc.2.26426.102`
- Target: Core framework-dependent debuggee
- GC: Workstation
- Analysis mode: Heap dump
- DAC: matching legacy `libmscordaccore.dylib`
- Test configurations:
- `SOS.Tests.SpecializedInspectionTests.SyncBlk_ReportsInflatedMonitor(config: scenarios/DotnetDump/Core/net11/Dump/Workstation/Heap)`
- `SOS.Tests.GcInspectionTests.VerifyHeap_ReportsNoCorruption(config: scenarios/DotnetDump/Core/net11/Dump/Workstation/Heap)`
- Observed in [dotnet/diagnostics#5981](https://github.com/dotnet/diagnostics/pull/5981)
- Helix jobs:
- [Release](https://helix.dot.net/api/jobs/2718285e-2bf4-4974-a981-46f59a9b9631/details)
- [Debug](https://helix.dot.net/api/jobs/3455d780-9a60-4bc0-bea0-19f6ef8c8299/details)

### Regression?

This does not appear entirely new. Diagnostics tests have skipped Unix `syncblk` validation since [667723e0](https://github.com/dotnet/diagnostics/commit/667723e07372492b89ab8b711bd5953f9529e94b) in October 2019, with the comment:

```text
On Linux/MacOS we sometimes get "Error requesting SyncBlk data" error from the DAC.
```

The new SOS.Tests harness makes the failure deterministic for this .NET 11 macOS scenario and also exposes the associated `verifyheap` false positive.

### Other information

- stderr is empty.
- The matching runtime and legacy DAC load successfully.
- Other SOS commands work in the same `dotnet-dump` session.
- Ubuntu Debug and Release both pass these exact .NET 11 legacy-DAC configurations.
- This is distinct from [dotnet/runtime#124691](https://github.com/dotnet/runtime/issues/124691), which implemented the cDAC `GetSyncBlockData` API.
- Related historical issue: [dotnet/runtime#11407](https://github.com/dotnet/runtime/issues/11407), which enabled `syncblk` on Unix.

Reproduce with dotnet-dump analyze heap.dmp using the listed runtimes and DAC options, then inspect the named SOS.Tests.SpecializedInspectionTests.SyncBlk_ReportsInflatedMonitor and GcInspectionTests.VerifyHeap_ReportsNoCorruption configurations. Compare the macOS x64 legacy-DAC behavior with the passing cDAC, LLDB, and Ubuntu runs. Done means syncblk lists the held SyncBlock and verifyheap reports 0 errors with no heap corruption detected.

Written by the indexing model from the issue text.