Fix DQ extension: wire up value / stripunits / calculate_residuals for Quantity

[ChrisRackauckas-Claude]

Summary

Supersedes #3492 (which I closed with a "just delete the test" patch; this fixes the underlying bugs instead).

The new DynamicQuantities+Measurements downstream test (abfbbd6) failed the Tsit5 solve at three separate points, all caused by DiffEqBaseDynamicQuantitiesExt not covering enough of DiffEqBase's wrapper-stripping surface. #3485's 8a3ffd5 patched solve.jl init to call DiffEqBase.value / DiffEqBase.stripunits, but the corresponding DQ overrides were never added — each helper fell back to identity on Quantity.

Three bugs fixed

1. SciMLBase.value / SciMLBase.unitfulvalue — parallel to the Unitful and FlexUnits extensions. value(::Quantity) = value(ustrip(x)) recurses so both the DQ wrapper and any inner Measurement/Dual are stripped. Without it, initdt.jl:320's eps(DiffEqBase.value(t)) errored with:

   MethodError: no method matching eps(::Quantity{Float64, Dimensions{FRInt32}})

2. RecursiveArrayTools.recursive_unitless_bottom_eltype / recursive_unitless_eltype — the upstream generic Number dispatch uses typeof(one(T)), and DynamicQuantities' one(::Type{<:Quantity}) returns a dimensionless Quantity{Float64, D}, so units survived the "unitless" transformation. Recurse into DynamicQuantities.value_type(T) instead so uBottomEltypeNoUnits becomes a bare scalar type and zero(uBottomEltypeNoUnits) at solve.jl:616 — the originally reported failure — lands on a valid Measurement{Float64}.

   Cannot create an additive identity from Type{<:DynamicQuantities.Quantity}

3. DiffEqBase.calculate_residuals — the scalar methods use @fastmath ũ / (α + …), which routes through Base.FastMath.div_fast and promotes its args. Promotion of Quantity{Measurement{Float64}, D} against a bare Measurement{Float64} tolerance fails ("promotion of types … failed to change any arguments"). Specialize for ũ::UnionAbstractQuantity (and the 5-arg (u₀, u₁, …) variant) to use plain /.

Each override is narrow — it only intercepts calls whose argument carries DQ units, so non-DQ code paths are untouched.

Verification

Ran the exact downstream test locally against the patched extension (dev-ed DiffEqBase, OrdinaryDiffEqCore, OrdinaryDiffEqTsit5 into a fresh project):

Test Summary:                                      | Pass  Total  Time
DynamicQuantities units + Measurements uncertainty |    4      4  5.4s

Failing CI that motivated this:
https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/24748633476/job/72406481107

Test plan

• CI Downstream group runs dynamicquantities_measurements.jl and it passes (4 asserts)
• Other downstream tests (Measurements-only, time-derivative) continue to pass — nothing touched on the non-DQ path