Initialize translational acceleration sensor test

[ChrisRackauckas-Claude]

This PR should be ignored until reviewed by @ChrisRackauckas.

Summary

• Initialize both physical states of the TranslationalPosition.AccelerationSensor test mass.
• Keep the existing fully determined initialization check and acceleration-versus-force assertion.

Root cause

The test constructed TranslationalPosition.Mass(m = 4) and then passed no initial conditions to ODEProblem(...; fully_determined = true). Current ModelingToolkit therefore correctly reports an underdetermined initialization system rather than selecting arbitrary initial position and velocity values.

ModelingToolkit source-history bisection identified b0f31536949370d189c03df71bc38f692a9a6975 (fix: avoid false positives in consistency check) as the first bad commit for this fixture:

• Parent 80f7f62bc0a8925dfef88f149c111c6dc812415e constructed the problem only because alias elimination silently forced underconstrained variables to zero.
• b0f3153694 intentionally replaced that behavior with IgnoreUnderconstrainedVariable; the same fixture then reported 4 highest-order derivative variables for 2 equations, including mass₊sˍt(t) and acc₊flange₊s(t).

Giving the mass explicit zero position and velocity is the physical assumption the test already relied on. This is distinct from the closed outputs= attempt in #450: outputs do not change structural balance. An explicit internal velocity inside AccelerationSensor was also tested and did not fix initialization; it only moved the singular variable.

Local verification

Using registry ModelingToolkit 11.31.2 and ModelingToolkitBase 1.51.1:

• Julia 1.12.6, exact PR head on MTSL main 06464384: test/translational.jl passed 16/16 (Free 2/2; spring/damper/mass/fixed 4/4; driven 4/4; sources and sensors 6/6).
• Julia 1.10.11, exact PR head: the same file passed 16/16.
• A focused solve with both initial conditions passed the existing physical assertion acc_output ≈ mass.f / m.
• Runic checked all 81 tracked Julia files successfully.
• git diff --check passed.

Process log

1. Searched open/closed issues and PRs, including Test suite red on master (latest MTK/SymbolicUtils): _clamp import + ExtraVariablesSystemException + fntype_X_Y; blocks downgrade re-enable #457 and closed PR test: declare dangling sensor / capacitor variables as outputs #450.
2. Reproduced the failure independently on clean MTSL main with the reported dependency versions.
3. Tested and rejected the outputs= and internal-velocity hypotheses.
4. Confirmed that both physical mass initial conditions are necessary and sufficient.
5. Bisected the behavior to ModelingToolkit commit b0f3153694 and inspected its removal of silent zeroing.
6. Rebasing onto current MTSL main, reran the focused file on Julia 1.12 and 1.10, then ran Runic and the diff check.

[ChrisRackauckas-Claude]

Investigation scratchpad / final local state:

• Clean failure: MTSL 2a9fc95e, MTK 11.31.2, MTKB 1.51.1, Julia 1.12.6; sources & sensors reported 5 pass / 1 error, with mass₊v(t) structurally singular.
• Formal MTK boundary: 80f7f62bc0 passed with no initial conditions; child b0f3153694 failed after it intentionally stopped silently zeroing underconstrained variables.
• Rejected alternative: an internal sensor velocity state preserved the equation/variable count but moved the singularity to acc₊flange₊sˍt(t).
• Exact PR head d698064b atop MTSL main 06464384: full test/translational.jl passed 16/16 on Julia 1.12.6 and 16/16 on Julia 1.10.11.
• Whole-repo Runic and git diff --check passed.

CI timing estimate: recent Tests workflows have taken about 34–67 minutes and IntegrationTest runs about 2h12–2h47. A conservative 3-hour check target is 2026-07-13 19:52:45 EDT.

[ChrisRackauckas-Claude]

CI classification for the independent SISO failures:

• In all three Core channels (Julia 1.10.11, 1.12.6, and 1.13.0-rc1), the changed translational test file passed 16/16. Each job later failed in test/utils.jl:41 with 13 pass / 1 error because initsol[sys.so.u] reported that so₊u(t) is not present in the system.
• In Downgrade, translational again passed 16/16. The later test/utils.jl:40 assertion failed because initsol[sys.so.xd] evaluated to 0.0 instead of 1.0; utils reported 13 pass / 1 fail.
• This PR changes only the translational AccelerationSensor initial conditions and cannot cause any of the later utils failures. A separate clean-main reproduction and dependency bisect is covering all resolver configurations; this PR will not absorb that unrelated fix.

QA and documentation are green. Downstream remains in progress.

[ChrisRackauckas-Claude]

I independently audited the remaining red jobs here. The translational file passes with this PR's change; the failures occur later in clean-main test/utils.jl SISO initialization and are unrelated to the AccelerationSensor patch.

• current/LTS/pre: initsol[sys.so.u] errors because the observed symbol is absent from the standalone initialization system;
• downgrade: initsol[sys.so.xd] evaluates to 0.0 instead of 1.0.

Draft #491 is the separate focused fix. Its ODEProblem path passes the complete utils file locally on the exact minimum stack, exact current-LTS stack, and Julia 1.12.6 current registry. No change to #489 is needed.

[ChrisRackauckas-Claude]

Terminal CI classification: all completed package Core lanes reach and pass the translational file with this change, then fail later at the separately fixed SISO initialization covered by stacked #491. The ModelingToolkit downstream failure is the independently reproduced same-process environment leak: LinearSolveArnoldiMethodExt resolves against a mismatched LinearSolve module and reports ArnoldiMethodJL undefined. That infrastructure fix is now in SciMLTesting draft #23 with the ModelingToolkit opt-in in draft #4749. No AccelerationSensor-specific CI failure appeared.