test/desauty: user-side alias break in Enzyme init closure (fixes SCC init @test_broken)

[ChrisRackauckas-Claude]

Note

Draft — please ignore until reviewed by @ChrisRackauckas.

Summary

The SCC init Enzyme test was @test_broken because the previous closure-based pattern misused Enzyme's API: Enzyme.gradient(set_runtime_activity(Reverse), Const(closure), itunables) doesn't allocate shadows for the closure's captured mutable state. Since the closure captured iprob (whose iprob.p.caches is shared with the new MTKParameters produced by irepack's @set!-based repack), the derivative info from the inner solve!'s cache writes had nowhere to land — and the gradient silently came out zero.

The fix is to use the idiomatic Enzyme pattern: a plain function whose captured mutable state is passed as an explicit Duplicated argument:

function enzyme_init_loss(t, iprob_)
    _, irepack_, _ = SS.canonicalize(SS.Tunable(), parameter_values(iprob_))
    iprob2 = remake(iprob_, p = irepack_(t))
    sol = solve(iprob2, NewtonRaphson())
    return sum(sol.u)
end
diprob = Enzyme.make_zero(iprob)
dtunables = zero(itunables)
Enzyme.autodiff(
    set_runtime_activity(Reverse),
    Const(enzyme_init_loss), Active,
    Duplicated(itunables, dtunables),
    Duplicated(iprob, diprob),
)

irepack is reconstructed inside the loss from the duplicated iprob_, so its captured parameter template shares Enzyme's shadow. With this change the SCC init gradient matches FD to 8 significant figures.

Verified locally:

• FD: [0, 0, 0.3663, 0.3101, 0, 0, 0.7325, 0, 0, 0]
• Enzyme: [0, 0, 0.3663, 0.3101, 0, 0, 0.7325, 0, 0, 0]

@test_broken → @test; both use_scc = false and use_scc = true branches share the same test body.

Companion PRs

These are independent SciML-side fixes uncovered during the investigation (legitimate bugs in their own right; needed for the test to pass cleanly):

• NonlinearSolveBaseEnzymeExt: accumulate non-Tunable cotangent fields (#935) NonlinearSolve.jl#936 — _accum_tangent! walks non-Tunable cotangent fields under diff_tunables = false (merged)
• NonlinearSolveBaseEnzymeExt: preserve prob.p / prob.u0 aliasing in return-value shadow NonlinearSolve.jl#937 — _make_solution_zero preserves sol.prob.p/u0 shadow alias
• DiffEqBaseEnzymeExt: port NS#936/937 fixes (caches walk + alias preserve) OrdinaryDiffEq.jl#3671 — same NS#936/937 fixes ported to DiffEqBaseEnzymeExt

Test plan

• Local desauty_dae_mwe.jl Enzyme block matches FD to 8 sig figs.
• CI green on full SciMLSensitivity suite.

[ChrisRackauckas-Claude]

CI is failing because the test requires SciML/NonlinearSolve.jl#936 (the _accum_tangent! caches walk in NonlinearSolveBase), which is merged on master at v2.26.1 but not yet registered — General registry still has v2.26.0 (pre-NS#936). Local runs match FD to 8 sig figs because they pick up NonlinearSolveBase from a dev'd path that includes NS#936; CI resolves to the registry version which doesn't have it.

Triggered the registrator on the NS#936 merge commit: SciML/NonlinearSolve.jl@a32ebd6#commitcomment-186443744

Once NonlinearSolveBase v2.26.1 lands in the General registry this PR's CI should pass without further changes (the compat in SciMLSensitivity's Project.toml is open enough already — it'll naturally pick up the new version).