JIT: fix slow preheader EH bookkeeping in loop cloning

[AndyAyersMS]

Fix a bug where loop cloning might improperly extend EH regions. This doesn't seem to be reachable with current cloning but I was running into it with some prototypes that did more general loop unswitching.

[AndyAyersMS]

@jakobbotsch PTAL
fyi @dotnet/jit-contrib

no diffs expected

[Copilot]

Pull request overview

This PR adjusts loop cloning’s EH-region extent bookkeeping when inserting the slow-path preheader so that any EH clauses ending at the actual insertion point (beforeSlowPreheader) are extended, preventing inadvertent EH region mis-sizing when the insertion point differs from the loop’s lexical bottom.

Changes:

• Update EH extent updates to key off beforeSlowPreheader (the actual insertion point) rather than bottom.
• Add clarifying comments explaining why enclosing EH regions may need to be extended before DuplicateWithEH.

[AndyAyersMS]

Here's what my local AI has to say:

The mismatched operand types come from the JIT's implicit-byref struct-argument rewrite. Import starts with the IL for if (&p == null):

ldarga.s 1
conv.u
ldc.i4.0
conv.u
bne.un.s

which initially imports as:

NE int
  LCL_ADDR long V01 arg1
  CAST long <- ulong <- uint
    CNS_INT int 0

Later, Morph - ByRefs changes the small struct argument p to an implicit byref:

Changing the lvType for struct parameter V01 to TYP_BYREF.

and global morph rewrites the address node:

LCL_ADDR long V01 arg1

into:

LCL_VAR byref V01 arg1

The zero side remains a CAST long <- ulong <- uint, so the compare reaches fgOptimizeRelationalComparisonWithCasts as a byref-vs-long/null comparison. That path was not exercised for EQ/NE until #128091 enabled this optimization for equality comparisons.

---

There is some logic in the stack allocation pass (which also rewrites pointer types) to try and make compensating changes for compares. We could do something like that here, or just bail on this case entirely.