Rebase of #3902 onto master (TSRKC2/TSRKC3 stage time hoist)

[ChrisRackauckas-Claude]

Please ignore until reviewed by @ChrisRackauckas. Opened as a draft.

Rebase of #3902 (by @Sreeram-Shankar) onto current master, as requested. Authorship on the commit is preserved.

Honest summary: this is a no-op

Rebasing #3902 onto master leaves two moved lines. Everything else in that PR is already on master, landed via other PRs. I am opening this because the rebase was asked for, not because I think it fixes anything — the surviving change has no observable effect.

What survives

th was assigned inside the if (iter < mdeg) guard in the in-place TSRKC2 and TSRKC3 stage loops; this hoists it out, matching RKC and RKMC2 which already compute it unconditionally.

It is a no-op because th is read only by the th1 = th on the next line, which stays inside the guard. Nothing observes the value computed on the final iteration — I checked that th appears exactly twice in each method (the assignment and that read), both inside the guard, and is never read after the loop.

The cost is one dead flop per step. The benefit is consistency with the sibling methods. Reviewer's call whether that trade is worth taking; closing this is a perfectly reasonable outcome.

What did not survive, and why

#3902 content	Status on master
RKL1/RKL2 non-autonomous stage times	Already landed, #3948
RKG1/RKG2 non-autonomous stage times	Already landed, #3949
RKC in-place mdeg < 2 handling	Superseded by buffer rotation, #3951
Per-algorithm limiter fields	Reverted by the author in c34fe7a73; superseded by solve-level limiters, #3835

Master computes stage times with the recursion cⱼ = μⱼcⱼ₋₁ + νⱼcⱼ₋₂ + μ̃ⱼ (+ γ̃ⱼ) rather than #3902's closed forms. I verified in exact rational arithmetic, for s ∈ {3,4,5,7,9,15,25}, that the recursion reproduces #3902's closed forms exactly for all four families:

• RKL1 j(j+1)/(s(s+1))
• RKL2 (j²+j−2)/(s²+s−2)
• RKG1 j(j+3)/(s(s+3))
• RKG2 (j+4)(j−1)/((s+4)(s−1))

So none of that analysis was lost in the reimplementation.

I also dropped four stray double-blank-lines and one unwrapped long line from #3902, which were Runic regressions.

Testing

GROUP=Core in lib/OrdinaryDiffEqStabilizedRK, run locally on this branch:

Test Summary: | Pass  Total     Time
RKC Tests     |  256    256  8m57.7s

Identical to master (256/256), as expected for a no-op. Runic reports the modified file clean.

Unrelated pre-existing failure on master

GROUP=QA fails on unmodified master, independent of this PR:

no_stale_explicit_imports: Module `OrdinaryDiffEqStabilizedRK` has stale
(unused) explicit imports for: * `trivial_limiter!`

trivial_limiter! is imported at lib/OrdinaryDiffEqStabilizedRK/src/OrdinaryDiffEqStabilizedRK.jl:13 and used nowhere in src/. Traced to c017e6c45 (#3835), which removed every use but left the import. Not fixed here to keep this PR to one thing.

🤖 Generated with Claude Code

https://claude.ai/code/session_018D9tiAHg9m8uQcz1H7QxcU