`@turbo` behavior change in Julia v1.11: bounds check triggered when using `indices`

Dear all,
In **Julia v1.10**, the following function using `@turbo` from **LoopVectorization.jl** runs without error and returns `10`:

```julia
using LoopVectorization

a = ones(10)
b = ones(11)

@inline function dot(A::AbstractArray{T}, B::AbstractArray{T}) where {T}
ret = zero(T)
@turbo for m ∈ indices((A, B), 1)
ret += A[m] * B[m]
end
ret
end

dot(a, b) # returns 10 in Julia v1.10
```

However, in **Julia v1.11**, the same code results in the following error:

```
ERROR: 10 and 11 are not equal.
```

This seems to stem from a bounds check triggered deep inside the `_static_promote` function from [Static.jl](https://github.com/SciML/Static.jl/blob/master/src/Static.jl#L326), likely when evaluating `indices((A, B), 1)` together with `@turbo`.

---

## Question

- Is this change **intentional** (i.e., a **feature**) or a **bug**?
- In previous versions, `@turbo` appeared to skip such bounds checks and worked leniently over the shortest matching dimension.
- In Julia v1.11, this stricter behavior is triggered — perhaps correctly — but it may break previous code that relied on implicit truncation via `indices`.

If this is intended, should users now explicitly write:
```julia
for m in 1:min(length(A), length(B))
```

While the bounds check may lead to more robust behavior, it also breaks backwards compatibility with earlier versions where this function ran fine.

I'd appreciate any clarification on whether this is expected behavior or if it indicates a bug in `@turbo` or a related change in how `indices` behaves with StaticArrays.

Thanks in advance!

LoopVectorization.jl を使用して Julia v1.10 と v1.11 で例を再現し、indices((A, B), 1) を指定した @turbo に焦点を当てます。Static.jl にあるリンク先の _static_promote 実装を読み、境界チェックが意図的なものかどうかを判断します。互換性の変更を明確にするか、報告された挙動のリグレッションを特定すれば完了です。

索引モデルが issue の本文から書いたものです。