Fix DAC AMD64 unwinder null deref on zero read address (#126081)

[steveisok]

The DAC's AMD64 stack unwinder reads target memory via MemoryRead64/128, which resolve to dac_cast<>::operator* -> DacInstantiateTypeByAddress. That helper's `preserve special pointer values'' fast-path returns a NULL host pointer for target addresses 0 and (TADDR)-1 without throwing, even though the read is invoked with throwEx == true. operator* then unconditionally dereferences the NULL, faulting inside the DAC itself (observed as 'segfault at 0 ... in libmscordaccore.so' on the DBI-Callback thread when an unwind step reads at ContextRecord->Rsp == 0).

Honor the read's throw-on-failure contract in the DAC build by rejecting the 0 / (TADDR)-1 special addresses in MemoryRead64/128 so the stackwalk aborts cleanly with a DacError instead of crashing. This covers every unchecked read site in the amd64 unwinder at once and is scoped to DACCESS_COMPILE, leaving the online/JIT unwinder unchanged.

Contributes to #126081

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR hardens the CoreCLR AMD64 unwinder when built for DAC (out-of-process debugging) by turning otherwise-fatal reads from “special” target addresses (0 and (TADDR)-1) into a clean DAC error instead of a null-pointer dereference inside libmscordaccore.

Changes:

• Add a DAC-only guard in MemoryRead64 to reject read addresses 0 and (TADDR)-1 and raise DacError(HRESULT_FROM_WIN32(ERROR_READ_FAULT)).
• Add the corresponding DAC-only guard in MemoryRead128 to prevent the same failure mode for 128-bit reads.