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

从 lib/RecursiveArrayToolsRaggedArrays/src/RecursiveArrayToolsRaggedArrays.jl 的第 1335、1347 和 1468 行附近开始，然后检查 AbstractRaggedVectorOfArray 的 .u 字段及其 copyto!/fill 路径。运行 RecursiveArrayToolsRaggedArrays JET QA 检查，以复现 similar_type(::Any) 报告。当这些 JET 发现不再出现在该 lane 中时，即表示完成。

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).