[LinearSolver.Direct] BTDLinearSolver::partial_solve: fix members initialization/bad values - #6227

Why your constraints hit it and the stock scenes mostly don't
The reads are only reachable if the first partial_solve() of the simulation takes neither step 2 nor step 3, because those two are what set both members to a sane value (bwdAccumulateLHGlobal() sets both to 0 at inl:517-520, fwdAccumulateRHGlobal() sets _indMaxFwdLHComputed = current_bloc).

In the unbuilt GS loop (UnbuiltGaussSeidelConstraintSolver.cpp:141-207), the first thing a correction sees is addConstraintDisplacement → partial_solve(Vec_I_list_dof[last_disp], …, NewIn=false). current_bloc is nb-1 at that point, so step 2 fires as long as MinIdBloc_OUT < nb-1 — i.e. as long as the first-processed constraint touches something other than the last node. Everything is initialized before it's read, and you never notice the bug.

You skip both steps when the first constraint block processed has Vec_I_list_dof[j].front() == nb-1, i.e. it acts only on the last block/node of the BTD system. That depends entirely on:

which DOFs your custom constraint writes into the Jacobian (LinearSolverConstraintCorrection.inl:745-768 builds Vec_I_list_dof from the Jacobian columns),
the order of constraints_sequence, and the wire_optimization renumbering at inl:504-532,
how many constraints there are and which corrections appear in cclist_elems[j].