JET: similar_type(::Any) no-matching-method in RecursiveArrayToolsRaggedArrays (pre-existing QA red)

The RecursiveArrayToolsRaggedArrays QA lane fails JET.test_package(...; target_defined_modules = true) with three similar_type(::Any) reports:

no matching method found `similar_type(::Any)`:
  StaticArraysCore.similar_type(((dest::RecursiveArrayTools.AbstractRaggedVectorOfArray).u::Any)[i::Any]::Any)

These originate from the copyto!/fill paths in lib/RecursiveArrayToolsRaggedArrays/src/RecursiveArrayToolsRaggedArrays.jl (lines ~1335, 1347, 1468): JET infers dest.u[i] / VA.u[i] as ::Any because the abstract AbstractRaggedVectorOfArray .u field is untyped, so StaticArraysCore.similar_type(::Any) has no matching method.

This is pre-existing on master (verified: a clean origin/master checkout of the RaggedArrays QA group reports 10 passed, 2 failed — the Piracy false-positive plus this JET finding — before any QA-harness conversion). It is not introduced by the run_qa v1.6 conversion (https://github.com/SciML/RecursiveArrayTools.jl/pull/621). The conversion keeps the JET check as a hard test (behavior-preserving), so this lane remains red until the inference issue is addressed (e.g. tightening the .u field type or guarding the immutable-similar_type branch).

Start in lib/RecursiveArrayToolsRaggedArrays/src/RecursiveArrayToolsRaggedArrays.jl around lines 1335, 1347, and 1468, then inspect the AbstractRaggedVectorOfArray .u field and its copyto!/fill paths. Run the RecursiveArrayToolsRaggedArrays JET QA check to reproduce the similar_type(::Any) reports. Done means these JET findings no longer occur in the lane.