Ensure that we properly set the morphed flag

[tannergooding]

This resolves #127138

In some cases we need to ensure the introduced node is explicitly marked as morphed since it may not be returning through fgMorphHWIntrinsic. This was a pre-existing issue, but one that only surfaced due to the fixed IsVectorPerElementMask check.

[dotnet-policy-service]

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

[tannergooding]

CC. @dotnet/jit-contrib for review. Resolves #127138

[Copilot]

Pull request overview

Fixes a CoreCLR JIT global morph (DEBUG) assertion by ensuring HWIntrinsic nodes introduced/updated during morph are explicitly marked as “morphed” when they won’t necessarily flow back through fgMorphHWIntrinsic as the returned node.

Changes:

• Mark the inner operand as morphed after required/optional morphing when folding creates a vector↔mask conversion that needs its inner node re-morphed.
• In fgMorphHWIntrinsicRequired, explicitly mark newly introduced/re-morphed nodes as morphed in transformation paths that attach them as operands (rather than returning them directly).

[kg]

Looks safe, makes me wonder if there are any TP regressions but I assume they would be small

[tannergooding]

makes me wonder if there are any TP regressions

Nothing measurable: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1387320&view=ms.vss-build-web.run-extensions-tab

Hardware intrinsics tend to be a minority of code so it typically doesn't show up on the overall measurements.