[wasm] Ensure R2R entry-point PEP is callable in RunMain

Summary

On WebAssembly, the managed program entry point is invoked from R2R-compiled code:
System.Environment.CallEntryPoint performs an indirect call through the entry
point's address. When the entry point resolves to a PortableEntryPoint (PEP) whose
actualCode slot has not yet been populated, that indirect call_indirect targets an
uninitialized table slot and the module traps (uninitialized element) — or, when the
condition arises on a cold path, the runtime falls back to interpreter execution for
the entire process instead of running R2R code.

This adds the missing call to MethodDesc::EnsurePortableEntryPointIsCallableFromR2R
in RunMainInternal (right after the entry-point address is materialized via
GetSingleCallableAddrOfCode()), so the entry-point PEP is published to real code
(native R2R body or a correctly-typed interpreter thunk) before it is invoked.

    pParam->pFD->EnsureActive();
    PCODE entryPoint = pParam->pFD->GetSingleCallableAddrOfCode();
#ifdef FEATURE_PORTABLE_ENTRYPOINTS
    // The entry point is invoked from R2R-compiled code (Environment.CallEntryPoint performs an
    // indirect call through this address), so it must resolve to real code (native R2R or a
    // correctly-typed interpreter thunk) rather than an uninitialized portable entry point.
    MethodDesc::EnsurePortableEntryPointIsCallableFromR2R(entryPoint);
#endif // FEATURE_PORTABLE_ENTRYPOINTS

Motivation

The helper MethodDesc::EnsurePortableEntryPointIsCallableFromR2R and its sibling
call-sites are already on main (introduced by #130386 and #130841). Those PRs cover
finalizer slots, FCall/PInvoke helpers, class constructors, string constructors, and
prestub paths — but not the program entry point invoked by RunMain. As a result,
a ReadyToRun WASM image that dispatches its Main through Environment.CallEntryPoint
can hit an uninitialized PEP and either trap or degrade to whole-program interpreter
execution.

This is the last uncovered publication site on the hello-world startup path. It is a
6-line addition scoped entirely under #ifdef FEATURE_PORTABLE_ENTRYPOINTS, which is
set only for CLR_CMAKE_TARGET_ARCH_WASM (see src/coreclr/clrfeatures.cmake), so it
has zero effect on non-wasm targets.

Validation

Measured on a composite R2R WASI "Hello world" (CoreLib + System.Runtime +
System.Console, crossgen'd --composite --targetos:wasi --targetarch:wasm, run under
wasmtime).

A robust health signal for "R2R actually executes" (as opposed to the program merely
surviving via interpreter fallback) is whether two guaranteed-reached corelib bodies —
System.String..ctor and System.SpanHelpers.Memmove — execute as R2R, together with
the absence of TryPublishR2R FAILED diagnostics.

With the fix, the two guaranteed-reached bodies run as native R2R, the reverse-thunk
fallback diagnostics disappear entirely, and the app prints its output and exits 42.
Result independently reproduced across three builds (identical 7 / 8 / 0 counts).

Note: exit code alone is not a sufficient signal — an image with the entry-point
PEP uninitialized can still print and exit 42 while executing zero R2R bodies (pure
interpreter fallback). The String..ctor + Memmove execution check is the meaningful
gate.

Risk

• Scoped to wasm only via FEATURE_PORTABLE_ENTRYPOINTS.
• Uses an existing, already-merged helper; no new API surface.
• Mirrors the established pattern of the other EnsurePortableEntryPointIsCallableFromR2R
  call-sites already on main.

Original prototype commit: wasm: ensure R2R entry-point PEP is callable in RunMain
(authored by Andy Ayers).