[MLIR] `affine-loop-fusion` misses sibling fusion for loops sharing a read-only memref

`affine-loop-fusion` misses a legal sibling fusion opportunity when two adjacent affine loops have identical bounds, both only read from the same input memref, and write to different memrefs. This results in a missed optimization.

The transformation is legal because there are no conflicting dependences between the two loops: the shared memref is read-only, and the stores target distinct allocations.

### Input Program

**input.mlir**

```llvm
module {
func.func @sibling_fusion(%arg0: memref<128xf32>) {
%alloc = memref.alloc() : memref<64xf32>
%alloc_0 = memref.alloc() : memref<64xf32>
affine.for %arg1 = 0 to 64 {
%0 = affine.load %arg0[%arg1] : memref<128xf32>
affine.store %0, %alloc[%arg1] : memref<64xf32>
}
affine.for %arg1 = 0 to 64 {
%0 = affine.load %arg0[%arg1 + 32] : memref<128xf32>
affine.store %0, %alloc_0[%arg1] : memref<64xf32>
}
return
}
}
```

### Command

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

Version: b0dc60f01ab0057eea54ce82ab5498118a60567c

Save the supplied program as input.mlir and run mlir-opt --affine-loop-fusion to inspect the current output. Trace the affine-loop-fusion entry point and dependence analysis to understand why the adjacent loops are not fused. Done means the legal sibling loops are fused for this input and the resulting output preserves both stores.

Written by the indexing model from the issue text.