[MLIR] `affine-loop-fusion` misses sibling fusion for loops with identical read-only patterns

`affine-loop-fusion` misses a legal sibling fusion optimization opportunity when two adjacent affine loops have the same bounds and perform identical loads from the same read-only memref, while storing results to different output memrefs. Fusing these loops is profitable because the identical loads from `%arg0[%arg3]` and `%arg0[%arg3 + 1]` can be further optimized after fusion.

### Input Program

**input.mlir**

```llvm
module {
func.func @sibling_loads(%arg0: memref<65xf32>, %arg1: memref<64xf32>, %arg2: memref<64xf32>) {
affine.for %arg3 = 0 to 64 {
%0 = affine.load %arg0[%arg3] : memref<65xf32>
%1 = affine.load %arg0[%arg3 + 1] : memref<65xf32>
%2 = arith.addf %0, %1 : f32
affine.store %2, %arg1[%arg3] : memref<64xf32>
}
affine.for %arg3 = 0 to 64 {
%0 = affine.load %arg0[%arg3] : memref<65xf32>
%1 = affine.load %arg0[%arg3 + 1] : memref<65xf32>
%2 = arith.mulf %0, %1 : f32
affine.store %2, %arg2[%arg3] : memref<64xf32>
}
return
}
}
```

### Command

```bash
mlir-opt --affine-fusion-loop input.mlir
```

Version: b0dc60f01ab0057eea54ce82ab5498118a60567c

Run mlir-opt --affine-fusion-loop on input.mlir to establish the current behavior, then trace the affine-loop-fusion handling of the two adjacent loops. Done means this reproducer recognizes the legal sibling-fusion opportunity while retaining the read-only loads and separate output memrefs.

Written by the indexing model from the issue text.