Define the piston test independent variable

[ChrisRackauckas-Claude]

This PR should be ignored until reviewed by @ChrisRackauckas.

Summary

• Import the public @independent_variables macro from its owning ModelingToolkitBase module.
• Define the piston test's independent variable explicitly instead of inheriting ModelingToolkit's extension-import sentinel.

Context

ModelingToolkit source-history bisection identified 2785a86207f9d96fbe4f9395a4346228a43e8dd3 (refactor: move DynamicQuantities to extension) as the commit that replaced the global independent variable with PleaseImportDynamicQuantities. ModelingToolkitStandardLibrary PR #483 defined an independent variable for motor.jl, but piston.jl still reproduced the same _check_if_dde(::Vector{Equation}, ::PleaseImportDynamicQuantities, ::Vector{System}) MethodError against current ModelingToolkit master.

This uses the same public-owner import pattern as #483 and changes only the test fixture.

Local verification

• Before the change, include("test/piston.jl") reproduced the PleaseImportDynamicQuantities MethodError.
• After rebasing onto MTSL main 2a9fc95e, the focused test passed: Piston cylinder wall | Pass 3 | Total 3 | 2m08.1s.
• In GROUP=Core, Core/motor.jl passed 6/6 and Core/piston.jl passed 3/3. The run later stopped on unrelated Core/rotational.jl failures that also reproduce on an unmodified MTSL main checkout and are being investigated separately.
• /home/crackauc/.juliaup/bin/julia +1.12 --startup-file=no -m Runic --check . exited 0.
• git diff --check exited 0.

[ChrisRackauckas-Claude]

Investigation scratchpad:

1. Reproduced the downstream failure with unmodified MTSL piston.jl against current ModelingToolkit master: _check_if_dde received PleaseImportDynamicQuantities.
2. Confirmed the already-merged motor fixture fix in Define the independent variable in the motor test #483 and traced the sentinel introduction to ModelingToolkit commit 2785a86207f9d96fbe4f9395a4346228a43e8dd3.
3. Added the equivalent explicit independent-variable definition to piston.jl in commit 55bc8802585d2631cea4e8a9ff10c8c32af4fbe6.
4. Rebased onto MTSL main 2a9fc95e; the focused piston test passed 3/3, repository-wide Runic passed, and git diff --check passed.
5. The Core harness reached and passed both motor (6/6) and piston (3/3), then stopped on unrelated rotational failures. Those reproduce on clean MTSL main and have been split into a separate investigation.

Next step: monitor this draft PR's CI and address any branch-related failure without expanding its scope.

[ChrisRackauckas-Claude]

Additional validation on the published commit 55bc8802585d2631cea4e8a9ff10c8c32af4fbe6:

• Julia 1.10.11 focused piston test: 3/3 passed in 36.4 seconds.
• Julia 1.12 focused piston test with ModelingToolkitStandardLibrary developed at this PR and ModelingToolkit developed from current master 4295500b12c8bdae5273ce7a888e86e1d0991b8e: 3/3 passed in 2m32.9s.
• Repository-wide Runic 1.7.0 check: exit 0.
• git diff --check: exit 0.

The later Core/rotational.jl failures remain out of scope here. A detached clean-main diagnostic at 2a9fc95e reproduced the rotational relationship failure with the same resolved Julia 1.10 test environment; it is being handed to a separate required base-failure investigation.

[ChrisRackauckas-Claude]

CI classification for 55bc8802585d2631cea4e8a9ff10c8c32af4fbe6:

• Downgrade: piston passes 3/3 in 13.9s; rotational passes 31/31; the job later fails at the unrelated test/thermal.jl:204 FixedHeatFlow with alpha=0.0 retcode assertion.
• Current Julia: piston passes 3/3 in 2.0s; the job later fails in rotational with the relationship assertion and ExtraVariablesSystemException in the sensors test.
• Julia LTS: piston passes 3/3 in 2.0s; the same two rotational failures occur later.
• Julia pre: piston passes 3/3 in 1.8s; the same two rotational failures occur later.

The rotational relationship failure was independently reproduced on detached, unmodified MTSL main 2a9fc95e with Julia 1.10.11 and the CI-resolved stack (ModelingToolkit 11.31.2, ModelingToolkitBase 1.51.1, OrdinaryDiffEq 7.1.2, OrdinaryDiffEqRosenbrock 2.4.0, SciMLBase 3.34.0, Symbolics 7.31.2, SymbolicUtils 4.40.0). The solve returned Success, but all 101 sampled residuals exceeded atol=1; the maximum absolute residual was 3141.910963169249 at t=0.7000525046175057 (w1=1101.1788377719251, expected -2040.732125397324). That clean-main failure is assigned to a separate bisect/fix audit and is not changed here.

The downgrade-only thermal failure is also outside this piston-only diff. It still needs its own unmodified-main reproduction before being classified as a base-branch regression.

[ChrisRackauckas-Claude]

CI reaches the separate pre-existing rotational regressions after the piston test passes. Those failures are fixed in follow-up #486, which is stacked on this branch; its fresh local run passes test/piston.jl 3/3 and test/rotational.jl 31/31 against current ModelingToolkit master. Keeping this PR piston-only preserves the focused two-commit review sequence.

[ChrisRackauckas-Claude]

The long ModelingToolkit downstream job completed after ~2 hours. Its failure is unrelated to the piston test-only patch: MTK's curated GROUP=All loads LinearSolve 3.87.0 in an earlier group, then activates the Downstream sub-environment, which resolves LinearSolve 4.3.0 ([loaded: v3.87.0]). The new LinearSolveArnoldiMethodExt from 4.3 then precompiles against the already-loaded 3.87 module and errors because LinearSolve.ArnoldiMethodJL does not exist there. This produces three downstream precompile errors through ControlSystemsMTK/MTSL.

The likely boundary is LinearSolve #1071 / v4.3.0, which introduced the extension; the underlying hazard is running multiple MTK group environments with different dependency versions in one GROUP=All process. I am queuing a separate clean-main reproduce/bisect and will test a fresh-process group split rather than altering #485.