adding GetPendingReJITID cDAC API

[rcj1]

No description provided.

[dotnet-policy-service]

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

[Copilot]

Pull Request Overview

This PR adds a full managed implementation of the GetPendingReJITID cDAC API, including argument validation, contract-based lookup, HRESULT translation, and debug assertions against the legacy DAC behavior.

• Added argument checks and HRESULT handling around ReJIT lookups
• Replaced expression-bodied member with expanded try/catch logic
• Introduced DEBUG-only assertions comparing to the legacy implementation

Comments suppressed due to low confidence (3)

src/native/managed/cdac/mscordaccore_universal/Legacy/SOSDacImpl.cs:1793

• The legacy fallback is only exercised under DEBUG. If you intend to preserve previous DAC behavior in release builds, consider invoking the legacy implementation when contracts are unavailable or unimplemented.

#if DEBUG

src/native/managed/cdac/mscordaccore_universal/Legacy/SOSDacImpl.cs:1767

• This new API implementation needs unit tests covering: valid pending ReJIT, non-pending paths, invalid arguments, and exception handling to ensure correct HRESULT and out-parameter behavior.

    int ISOSDacInterface7.GetPendingReJITID(ClrDataAddress methodDesc, int* pRejitId)

src/native/managed/cdac/mscordaccore_universal/Legacy/SOSDacImpl.cs:1769

• Comparing methodDesc to 0 may not correctly detect a null address and could fail to compile. Use the appropriate null check on the ClrDataAddress type (e.g., a hypothetical methodDesc.IsNull) or compare against default(ClrDataAddress).

        if (methodDesc == 0 || pRejitId == null)

[max-charlamb]

lgtm 👍 only test failure is the known COM double free issue I'm investigating