Add Mooncake extension for ArrayPartition cotangents

[ChrisRackauckas-Claude]

Summary

When an upstream ChainRules-based adjoint (e.g. SciMLSensitivity's `_concrete_solve_adjoint` for an ODE whose state is an `ArrayPartition`, such as the one produced by `SecondOrderODEProblem`) returns a parameter / state cotangent as an `ArrayPartition`, Mooncake's `@from_chainrules`/`@from_rrule` accumulator looks for an `increment_and_get_rdata!` method matching

```julia
(FData{NamedTuple{(:x,), Tuple{Tuple{Vector, …}}}}, NoRData, ArrayPartition)
```

There isn't a default method registered for this combination, so the call falls through to the generic error path:

```
ArgumentError: The fdata type Mooncake.FData{@NamedTuple{x::Tuple{Vector{Float32}, Vector{Float32}}}},
rdata type Mooncake.NoRData, and tangent type
RecursiveArrayTools.ArrayPartition{Float32, Tuple{Vector{Float32}, Vector{Float32}}}
combination is not supported with @from_chainrules or @from_rrule.
```

Fix

Add the missing dispatch via a new `RecursiveArrayToolsMooncakeExt` weak-dep extension. An `ArrayPartition`'s only field is `x::Tuple` of inner arrays, so the FData layout is `FData{@NamedTuple{x::Tuple{...}}}` and the inner tuple positions line up with `t.x`. Walk the tuple element-by-element and forward each leaf to the existing `increment_and_get_rdata!` for the leaf's array type, which does the actual in-place accumulation. Returns `Mooncake.NoRData()` to match the no-rdata convention used by the equivalent ComponentArrays dispatch (SciML/ComponentArrays.jl#350 / #351).

This is a tiny additive extension — it only adds a method for a previously-unsupported `(FData, NoRData, tangent)` combination, so existing Mooncake users of `RecursiveArrayTools` are unaffected.

Test plan

• End-to-end against the SciMLSensitivity `SecondOrderODEProblem` tutorial (via concrete_solve: unwrap ArrayPartition cotangents in df_iip/df_oop SciMLSensitivity.jl#1422, which adds the matching `df_iip`/`df_oop` cotangent unwrap on the SciMLSensitivity side): with both PRs applied, the Lux + `ArrayPartition` training loop now runs under `OPT.AutoMooncake(; config = Mooncake.Config(; friendly_tangents = true))`
• Happy to add a unit test if you'd like — let me know what shape (mirror of an existing extension's tests, against a synthetic FData/ArrayPartition pair)

Related

• concrete_solve: unwrap ArrayPartition cotangents in df_iip/df_oop SciMLSensitivity.jl#1422 — companion fix in SciMLSensitivity `df_iip`/`df_oop`
• Add friendly_tangent_cache function to Mooncake ComponentArrays.jl#350 / ci: explicitly specify token for codecov #351 — analogous `friendly_tangent_cache` + `increment_and_get_rdata!` plumbing for `ComponentArray`
• Part of the [WIP] docs: prefer Mooncake over Zygote where it works end-to-end SciMLSensitivity.jl#1419 docs migration

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Rebased onto current master (was CONFLICTING / DIRTY, now CLEAN / MERGEABLE).

What changed

The original branch was cut from v3-backport, not master, so it carried 15 unrelated ancestor commits (FastBroadcast Serial/Polyester v3-line fixes and the v3.52–v3.54 version bumps — all already merged on v3-backport via #556, #560, #564/#566, #568, #569). None of those belong on master; master already has its own equivalent Polyester extension via #565/#567/#571 and is on v4.0.1. Nothing else was supposed to be merged — just the Mooncake commit.

Dropped all of the v3-backport ancestry and kept only the Mooncake commit (8ffc584). While rebasing I found two things worth fixing in a follow-up commit:

1. The Mooncake Project.toml patch landed in [deps] instead of [weakdeps] because the cherry-pick's context lines matched inside master's shorter [deps] block (master already has CUDA in [weakdeps], so alphabetical-position drift). Moved it to [weakdeps] so the extension stays weakly loaded.
2. Mooncake wasn't in [extras] / [targets.test], so the new extension was never exercised in CI. Added it, and added test/mooncake.jl as a direct unit test for Mooncake.increment_and_get_rdata!(::FData{@NamedTuple{x::T}}, ::NoRData, ::ArrayPartition{P, T}): constructs a matching FData and ArrayPartition, calls the method, and asserts in-place accumulation on each inner-array leaf is correct and the return is NoRData(). Also covers a three-way Float32 partition to exercise a different eltype and arity. Registered under the Core test group in runtests.jl.

Local test run (Pkg.test on Julia 1.10.11):

Test Summary:  | Pass  Total  Time
Mooncake Tests |    8      8  1.0s
...
Testing RecursiveArrayTools tests passed

Aqua (including test_stale_deps) passes, full Core group green.