[InstCombine] Infinite loop: sinking freeze fights freezeOtherUses

InstCombine can infinite-loop on a freeze whose operand has other uses. tryToSinkInstruction moves the freeze into a unique-successor user block; visitFreeze → freezeOtherUses then moves it back to the operand’s definition. If those extra uses are never rewritten (the freeze still does not dominate them), the two transforms ping-pong forever.

Reduced test case

```llvm
declare ptr @get()
declare void @escape(ptr)
declare i32 @__gxx_personality_v0(...)
define void @dont_sink_freeze_of_invoke_used_by_phi(i1 %c, ptr %other) personality ptr @__gxx_personality_v0 {
entry:
%p = invoke ptr @get() to label %join unwind label %lpad
join:
; %p is used by this phi on the invoke's normal edge. freezeOtherUses
; places freeze after the phis, so it never dominates that use.
%phi = phi ptr [ %p, %entry ], [ %other, %join ]
%fr = freeze ptr %p
br i1 %c, label %use, label %join
use:
call void @escape(ptr %fr)
call void @escape(ptr %phi)
ret void
lpad:
%lp = landingpad { ptr, i32 } cleanup
ret void
}
```

Reproduce

```
opt reduced.ll -passes=instcombine -S
# also hangs under -O3
```

-debug-only=instcombine shows the same instruction forever:

```
IC: Sink: %fr = freeze ptr %p
IC: Visiting: %fr = freeze ptr %p
IC: Mod = %fr = freeze ptr %p
New = %fr = freeze ptr %p
ADD: %fr = freeze ptr %p
```

Run the reduced.ll reproducer with opt -passes=instcombine -S and inspect the InstCombine paths named in the report: tryToSinkInstruction, visitFreeze, and freezeOtherUses. Trace why the freeze moves between the unique-successor block and the operand definition, then add a regression test showing that InstCombine terminates without the transforms ping-ponging.

Written by the indexing model from the issue text.