Initialize translational acceleration sensor mass

[ChrisRackauckas-Claude]

This PR should be ignored until reviewed by @ChrisRackauckas.

Summary

• initialize the TranslationalPosition acceleration-sensor fixture's mass position and velocity at component construction
• keep the fixture fully determined under current ModelingToolkit initialization checks

Root cause

TP.Mass stopped supplying s = 0 and v = 0 defaults in #305, but this fixture continued constructing it with only m. ModelingToolkit v11.10.0 exposed that underconstraint after b0f31536949370d189c03df71bc38f692a9a6975 stopped alias elimination from silently zeroing underconstrained variables. With ModelingToolkit v11.31.2, ODEProblem(...; fully_determined = true) therefore reports a structurally singular mass₊v(t) initialization system.

Providing the initial state on TP.Mass is the smallest fix and establishes the state before mtkcompile. This extracts the same focused fixture correction from the broader #452; the outputs approach attempted in #450 does not alter structural balance.

Local verification

• Julia 1.10.11: test/translational.jl — 16/16 passed
• Julia 1.12.6: test/translational.jl — 16/16 passed after rebasing onto 06464384
• Julia 1.13.0-rc1: test/translational.jl — 16/16 passed
• explicit acceleration diagnostic — maximum error against sin(4πt) / 4 was 0.0
• Runic v1.7.0: full-repository --check exited 0
• native stacked GROUP=Core with Define the piston test independent variable #485–Fix underdetermined thermal heat-flow sensor test #488: Core/translational.jl passed 16/16; the overall group later exited 1 in the unrelated Core/utils.jl SISO check, which is being handled as a separate clean-main audit

[ChrisRackauckas-Claude]

Investigation scratchpad:

1. Reproduced on untouched MTSL 2a9fc95e with Julia 1.12.6 and the exact current graph: ModelingToolkit 11.31.2, SciCompDSL 1.0.1, OrdinaryDiffEq 7.1.2, OrdinaryDiffEqRosenbrock 2.4.0, and LinearSolve 4.3.0. mtkcompile completed, but ODEProblem(...; fully_determined = true) failed during initialization as structurally singular at mass₊v(t). The full file reported 15 passes and one error in sources & sensors.
2. The fixture was added in 80b3c7f7 while TP.Mass supplied s = 0, v = 0. MTSL Remove more unnecessary defaults #305 (6ff870b41d8cfa74c18c85240ab6934aa8a7a87a) removed those defaults without updating this fixture.
3. ModelingToolkit release boundary: 11.9.1 passed; 11.10.0 failed as underbalanced. Exact source boundary: parent 80f7f62bc0a8925dfef88f149c111c6dc812415e passed, while b0f31536949370d189c03df71bc38f692a9a6975 failed. That change replaced ZeroVariablesIfFullyDetermined! with IgnoreUnderconstrainedVariable, so alias elimination no longer silently supplies zero for the missing state.
4. Tested constructor and post-compile initialization variants. TP.Mass(m = m, s = 0, v = 0) constructed, solved, and produced maximum acceleration error 0.0 against sin(4πt) / 4. Supplying the eliminated/bound mass variables after mtkcompile was not a reliable route on this graph because they did not all retain an Initial parameter.
5. Validation: focused file passed 16/16 on Julia 1.10.11, 1.12.6, and 1.13.0-rc1. Runic 1.7.0 full-tree check passed. A native GROUP=Core stack with the now-merged Define the piston test independent variable #485–Fix underdetermined thermal heat-flow sensor test #488 passed Core/translational.jl 16/16 and all preceding files, then exited 1 at the unrelated final Core/utils.jl SISO check (sys.so.u absent); that clean-main audit is intentionally separate.
6. Prior art: test: SISO Check uses ODEProblem instead of generate_initializesystem #452 contains the same one-line constructor correction among unrelated changes; test: declare dangling sensor / capacitor variables as outputs #450's outputs approach cannot change the initialization balance.
7. Push safety: a concurrent remote branch appeared after the initial absence check at d698064b, using post-compile ODEProblem state pairs. I did not overwrite it. This tested constructor-level commit was pushed on the fresh agent/fix-translational-acceleration-constructor-init branch.

[ChrisRackauckas-Claude]

The first completed Core failure is unrelated to this PR's translational change:

• Julia LTS Core passes Core/translational.jl 16/16, then errors later in Core/utils.jl at the SISO lookup initsol[sys.so.u] because so₊u(t) is absent (13 pass, 1 error in that file).
• The mandatory separate audit reproduced the identical SISO error on an untouched current upstream master (064643846) with the resolved current graph and is now bisecting/fixing it independently.

No SISO assertion or initialization behavior is changed in this focused translational PR.

[ChrisRackauckas-Claude]

The remaining Core matrix is consistent with the same separate SISO regression:

• Julia current and prerelease match LTS exactly: Core/translational.jl passes 16/16, then Core/utils.jl:41 cannot observe sys.so.u.
• Downgrade reaches the older dependency-graph form at utils.jl:40: initsol[sys.so.xd] is 0.0 instead of 1.0 (13 pass, 1 fail).

The separate clean-main audit was explicitly tasked with classifying both current and downgrade forms and determining whether they share one root cause. All three Julia versions verify this PR's translational target before the unrelated utils failure.

[ChrisRackauckas-Claude]

Superseded by the now-validated focused draft #489 and its stacked SISO follow-up #491. #489 covers the same AccelerationSensor initialization defect, passes the same 16/16 translational target on Julia 1.10 and 1.12, and carries the formal ModelingToolkit boundary evidence. Keeping both alternative fixture placements open would duplicate review and CI. The constructor-level branch and its investigation remain available in history, but no review was posted here and no contributor work is being overwritten.