fix for largepages with agressive decommit logic

[mangod9]

clear decommitted memory in the largepages scenario. Fixes #126903

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Fixes a GC heap-corruption scenario when GCLargePages is enabled and an induced Aggressive GC triggers “decommit” bookkeeping that doesn’t actually decommit at the OS level for large pages. The change ensures the memory that is treated as decommitted is explicitly cleared so stale references can’t be observed later.

Changes:

• In the induced-aggressive path of gc_heap::distribute_free_regions, clear the region tail that would normally be decommitted/zeroed by the OS.
• Gate the clearing to use_large_pages_p, since only large pages make virtual_decommit a no-op while still updating GC bookkeeping.

[janvorli]

LGTM, thank you!

[janvorli]

@mangod9 I believe this change should get in as is. But I wonder if it would be better to integrate the clearing of used part of the large page into the virtual_decommit (adding an "end of used data" argument) in the future so that we prevent similar issues to occur due to some changes in the GC. I also wonder if all the other usages of virtual_decommit are fine for large pages w.r.t. the fact the memory is not cleared.