`@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!