Deprecated ExaCore() call warns on every :exa model, leaking a package path into built documentation

[ocots]

Summary

src/onepass.jl:1483 calls ExaCore in its deprecated form, so ExaModels emits a deprecation
warning for every :exa model built. In a documentation build that warning lands on the
published page, together with the absolute path of the build machine's package store.

Reproduction

Any :exa solve:

using OptimalControl, ExaModels, NLPModelsIpopt
# ... any coordinatewise ocp ...
solve(ocp, :exa; display=false)

┌ Warning: `ExaCore()` is deprecated, and will be removed. Use `ExaCore(concrete = Val(true))`
│ for the immutable ExaCore. The default behavior for `ExaCore()` will change to return the
│ immutable ExaCore.
└ @ ExaModels ~/.julia/packages/ExaModels/bwVNw/src/deprecated.jl:30

Cause

src/onepass.jl:1483:

$p_ocp = $pref.ExaCore(
    base_type;
    backend=backend,
    minimize=($p.criterion == :min),
)

Why this surfaced now

solve/choosing-a-method.md in the OptimalControl documentation is the first page in that site
to run the :exa modeler live — solve/gpu.md is Draft = true, and solve/options.md's
:exa blocks are inert. Before that, no CI documentation build had ever executed this path, so
the warning had nowhere to appear.

Rendered into the page, the block reads:

┌ Warning: `ExaCore()` is deprecated, ...
└ @ ExaModels ~/.julia/packages/ExaModels/bwVNw/src/deprecated.jl:30
Line 6: (∂(q))(t) == v(t)
unknown numerical scheme: gauss_legendre_2 (possible choices are ...)

One line of signal, three of noise — and in CI the path becomes
/home/runner/.julia/packages/ExaModels/…, published on the site. The documentation currently
works around it with an explicit with_logger(NullLogger()) inside the block, which is
scaffolding a reader should not have to see. See control-toolbox/OptimalControl.jl#877.

Suggested fix

Move to the non-deprecated call so the warning stops at the source. Per the deprecation text
that is ExaCore(base_type; concrete = Val(true), ...), but the ExaModels release notes are the
authority on the intended replacement, and the concrete choice is a real decision about which
ExaCore the generated code should build — worth confirming rather than applying blindly.

Once fixed, the with_logger wrapper comes out of the documentation.

🤖 Generated with Claude Code

[ocots]

This issue is addressed by PR #326: #326

The PR updates CTParser to ExaModels 0.12, where the deprecated ExaCore() shim is no longer present. As a result, the generated :exa models no longer emit the deprecation warning. The PR deliberately keeps the default ExaCore configuration rather than adding concrete = Val(true), because the latter would cause unnecessary recompilation during model construction.

The fix is implemented and the test suite is passing. This issue will be closed automatically once PR #326 is merged.