Run tests with JULIA_NUM_THREADS=2 so #570 regression test is covered

[ChrisRackauckas-Claude]

Summary

• Issue Multi-threading VectorOfArray of SVectors is broken on RecursiveArrayTools.jl version 4 #570 reported @.. thread=true on VectorOfArray{SArray} blew up on v4.0.1. PRs Multithreading with RecursiveArrayTools.VectorOfArray is broken #564/Add Polyester threading extension for FastBroadcast VectorOfArray #567 already fixed the dispatch path on master (base-ext ::Threaded fallback → Serial, plus a Polyester ext for <:AbstractVector{<:SArray} storage), and master does handle Ranocha's reproducer correctly — verified locally against a Pkg.develop'd master.
• However, the regression testset added in Multithreading with RecursiveArrayTools.VectorOfArray is broken #564 (test/interface_tests.jl "Threaded @.. with VectorOfArray{SArray}") only triggers the failing code path when Threads.nthreads() >= 2. FastBroadcast's Polyester-backed threaded materialize splits work along the last axis via view(dst, :, r); with a single thread that split is a no-op and the bad scalar setindex! loop is never reached.
• Previously .github/workflows/Tests.yml delegated to SciML/.github/.github/workflows/tests.yml@v1, which does not accept a thread-count input and does not set JULIA_NUM_THREADS, so CI ran with Threads.nthreads() == 1 and the regression test silently passed without covering the bug.
• Inline the test job (dropping the reusable workflow) and set JULIA_NUM_THREADS: "2" as env on the julia-actions/julia-runtest@v1 step. Mirrors SciML/OrdinaryDiffEq.jl's SublibraryCI.yml, which passes JULIA_NUM_THREADS: ${{ matrix.num_threads }} the same way. No test-file changes needed.

Root cause (for context, already fixed on master)

1. @.. thread=true v = v + u on VectorOfArray{Float64,2,Matrix{SVector{2,Float64}}} dispatches to FastBroadcast.fast_materialize!(::Threaded, dst, bc).
2. On v4.0.1 there was no ::Threaded method for VectorOfArray in the RAT extension, so dispatch fell through to the fully generic FastBroadcast.jl:215 fallback → Polyester batches work by taking view(dst, :, r), producing a SubArray wrapping the VoA.
3. Each batch then called FastBroadcast's generic __fast_materialize! scalar loop → subview[i,j] = value → VectorOfArray.setindex!(VA, v, I::Int...) at src/vector_of_array.jl:904 → VA.u[col][inner_I...] = v → setindex!(::SVector, …) which throws on the immutable SVector.
4. Multithreading with RecursiveArrayTools.VectorOfArray is broken #564/Add Polyester threading extension for FastBroadcast VectorOfArray #567 added a base-ext fast_materialize!(::Threaded, ::AbstractVectorOfArray, ::Broadcasted) fallback that shunts to Serial(), avoiding the view-splitting path, plus a Polyester ext that genuinely threads <:AbstractVector{<:SArray} storage. The Matrix{<:SArray} case from Ranocha's reproducer still only runs serially (the type alias is <:AbstractVector{<:SArray}), but the fallback keeps it correct.

Test plan

• Local: ran test/interface_tests.jl with JULIA_NUM_THREADS=2 against a Pkg.develop'd master → Threaded @.. with VectorOfArray{SArray} | 2 pass.
• Local: ran Ranocha's exact reproducer from Multi-threading VectorOfArray of SVectors is broken on RecursiveArrayTools.jl version 4 #570 under JULIA_NUM_THREADS=2 against master → v = [2.0 2.0 2.0 2.0; 2.0 2.0 2.0 2.0]; against v4.0.1 the same reproducer still throws as reported.
• CI green on the existing {version × group} matrix, now with 2 threads per job.

Follow-up (not in this PR)

• v4.0.1 itself is still broken for users; once this is merged and CI confirms the regression is genuinely exercised, a v4.0.2 patch release off master would close the user-visible side of Multi-threading VectorOfArray of SVectors is broken on RecursiveArrayTools.jl version 4 #570.

🤖 Generated with Claude Code