[mlir][arith] Fix SelectOp unsafe int range inference with uninitialized range case (#173716)

This PR fixes a bug in `arith::SelectOp::inferResultRangesFromOptional`
where uninitialized SelectOp branch int ranges were incorrectly joined
with initialized int ranges during dataflow analysis, leading to
incorrect folding in `-int-range-optimizations`.

**The Issue:**
When a `arith.select` branch has an uninitialized range (e.g., from an
op like `nvvm.read.ptx.sreg.cluster.ctaid.x`, `scf.switch`, `llvm.call`,
... that lacks range inference), the analysis computed
`IntegerValueRange::join(Uninitialized, Constant) = Constant`. This
caused the `arith.select` to be replaced with the constant, ignoring the
dynamic branch.

**Example:**
```mlir
// The bug before fix: -int-range-optimizations replaces %1 with %c32
// led to incorrect results and unsafe behaviours
%0 = nvvm.read.ptx.sreg.cluster.ctaid.x : i32 // Uninitialized int range
%c32 = arith.constant 32 : i32
%1 = arith.select %cond, %0, %c32 : i32
```

**The Fix:**
Explicitly ensure `inferResultRangesFromOptional` all select cases have
initialized ranges before combining them. If any case is uninitialized,
the result is now treated as max range. Also added default max range for
`nvvmInferResultRanges` and `test.without_bounds` op to simulate and
test uninitialized ranges.

---------

Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>