[release/10.0] Preserve module initialization across ReadyToRun inlining

[AaronRobinsonMSFT]

Fixes Issue #134283

main PR #134359

Description

Backports the ReadyToRun module-activation fix from #134359 to release/10.0.

Composite ReadyToRun can inline away the call that activates another assembly, leaving its module initializer unexecuted. This preserves activation dependencies for cross-module inlining, permits the global module type's stable token outside the version bubble, and activates the declaring module before resolving RVA static fields.

The executable regression coverage from the main PR is included. The compiler-test runner changed by the main PR no longer exists on release/10.0, so that test-only change is intentionally omitted and the production fix is adapted to the older token-resolution implementation.

Customer Impact

Without this fix, ReadyToRun-published applications can observe incorrect state when a module initializer's activation call is removed by cross-module inlining. In the reported case, an UnsafeAccessor write performed by a module initializer is not observed and a private static field incorrectly remains unset.

Regression

No. The original report confirms the issue also reproduces on .NET 10.

Testing

• .\build.cmd clr+libs+host -arch x64 -rc Checked -lc Release
  • Blocked before the changed code compiled by an existing release-branch/toolchain incompatibility: src\coreclr\inc\crosscomp.h redefines CONTEXT_UNWOUND_TO_CALL, which is also defined by Windows SDK 10.0.28000.0; warning C4005 is treated as error C2220.
• No further .NET 10 tests were run after the required baseline build failed.

Risk

Moderate. The production changes are the narrowly scoped ReadyToRun fix already merged to main, adapted to the older release/10.0 token-resolution implementation, and the executable regression tests are included. Local validation is limited by the unrelated Windows SDK compatibility failure described above, so CI validation is required.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Note

This pull request was prepared with GitHub Copilot assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[jkotas]

Why are these changes needed?