Fix iOS arm64 CoreCLR crash from shared MethodDesc::CalliCookie slot

[kotlarmilos]

Problem

PR #127016 updated MethodDescCodeData::CallStub added a new writer in CInterpreterJitInfo::GetCookieForInterpreterCalliSig that caches a calli signature CallStubHeader* on the P/Invoke target MethodDesc.

PR #127016 added a small "calli cookie" cache. Each managed method has one slot where this cookie is stored. The problem is that two different parts of the runtime now write to that one slot:

• The interpreter-to-native call path stores a helper that's set up for the method's own signature
• The new code in [wasm][coreclr] Cache calli cookies #127016 stores a helper that's set up for the signature of a calli instruction inside an IL stub.

On iOS, when an app tries to execute address 0 the kernel does not give us a normal crash. It assumes the page is unsigned/tampered and kills the process with SIGKILL and a CODESIGNING / Invalid Page reason.

Proposed fix

Drop the new pContextMD->{Set,Get}CalliCookie cache reads/writes in CInterpreterJitInfo::GetCookieForInterpreterCalliSig. The function now always computes the cookie via GetCookieForCalliSig(sig, pContextMD), matching pre-#127016 behavior.

Fixes #127869 #127863 #127867

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[jkotas]

Github does not allow me to comment on this PR inline for some reason (hitting internal github errors).

A better wording of the comment:

    // Do not cache the cookie on pContextMD: MethodDesc::CalliCookie is for
    // calling the target via managed calling convention. The stub we are about
    // to generate calls the target via unmanaged calling convention.