Restore DelayDiffEq 6.1 DEOptions compatibility

[ChrisRackauckas-Claude]

Ignore until reviewed by @ChrisRackauckas.

Summary

• Restore the positional DEOptions constructor layout used by registered DelayDiffEq 6.1.0, supplying trivial_limiter! for the later-added stage and step limiter fields.
• Add a pinned downstream regression that exercises the public init/solve! path and verifies both limiter fields.
• Add the already-public, docstringed DEOptions type to the rendered OrdinaryDiffEqCore API page.

Root cause

c017e6c452883848ad86255de5ca3a1d033ebe83 added two limiter fields to DEOptions. DelayDiffEq 6.1.0 still constructs the intermediate 21-type-parameter/41-argument layout, while the pre-existing compatibility constructor only covers an older 21-type-parameter/46-argument layout. The released package therefore hits a MethodError during init.

The added constructor is backward-compatible and does not introduce or remove a public name.

Validation

• Bisected the released DelayDiffEq init failure from good fde6e1e6bcd93d3e4c40c16038af9593c69e6ece to first bad c017e6c452883848ad86255de5ca3a1d033ebe83.
• Ran the exact registered DelayDiffEq 6.1.0 regression locally: 4/4 assertions passed.
• Ran GROUP=Downstream julia +1.12 --project=. -e 'using Pkg; Pkg.test()': the new DelayDiffEq compatibility set passed 4/4 and the existing time-derivative set passed 202/202. Resolution used SciMLBase 3.39.1 because the current 3.40 floor is not registered; no temporary package-floor edits are included here.
• The remainder of that Downstream run reaches an independent DynamicQuantities 1.13 error that also reproduces on unmodified fd3f95bb99 master. It is not skipped or silenced and is being investigated separately.
• Runic passes on every changed Julia file. A whole-tree Runic check only reports pre-existing DISCO formatting differences, which are being handled separately.
• git diff --check passes.

[ChrisRackauckas-Claude]

Hosted-CI checkpoint on amended head 813afcb824:

Representative root, documentation, and sublibrary jobs stop during dependency resolution because the current OrdinaryDiffEq master copy of OrdinaryDiffEqNonlinearSolve requires unregistered SciMLBase 3.40 while General ends at 3.39.1. That clean-master floor is isolated in #4066. Runic reports the separately isolated clean-master DISCO formatting files from #4064. The quick SciMLSensitivity and PositiveIntegrators downstream failures are the independent compatibility boundaries recorded on #4066.

These setup failures occur before the DelayDiffEq compatibility regression is loaded. The exact registered DelayDiffEq 6.1.0 init/solve! test on this head passed 4/4 locally, and no resolver workaround or unrelated prerequisite is being added to this focused PR. The remaining hosted jobs are still being monitored.

[ChrisRackauckas]

Instead we should retrocap

[ChrisRackauckas-Claude]

Agreed. I am replacing this compatibility-constructor approach with a registry retrocap. The locally identified boundary is OrdinaryDiffEqCore 4.8.1: registered DelayDiffEq 6.0.0–6.1.0 works with Core 4.8.0, while the new DEOptions layout starts in 4.8.1. I am validating a General compat split of DelayDiffEq 6–6.1.0 against OrdinaryDiffEqCore 4–4.8.0; once that resolver/solve check passes and the registry draft is open, I will close this PR rather than rebase it.

[ChrisRackauckas-Claude]

Superseded by the registry corrections:

• Correct OrdinaryDiffEqDefault 2.4.1 Core floor JuliaRegistries/General#162780 gives the exact OrdinaryDiffEqDefault 2.4.1 release its required OrdinaryDiffEqCore 4.11 floor.
• Retroactively cap DelayDiffEq at OrdinaryDiffEqCore 4.8.0 JuliaRegistries/General#162781 caps DelayDiffEq 6.0.0–6.1.0 at OrdinaryDiffEqCore 4.8.0, before the incompatible DEOptions layout.

The final stacked registry resolution selected DelayDiffEq 6.1.0, OrdinaryDiffEqCore 4.8.0, and OrdinaryDiffEqDefault 2.4.0. The representative delayed problem then passed all 4 targeted checks through the public init and solve! path.

Closing this source-level compatibility constructor in favor of the reviewed retrocap direction.