`SubmitNodeCollection` applies the `forceSolidModelPhase` OIT safety guard inconsistently

While investigating the root cause of MC-310235 ("The game crashes when a piston pushes a water cauldron with the 'Improved Transparency' option enabled") by reading the client's decompiled source, I found that the crash is a symptom of a broader inconsistency in net.minecraft.client.renderer.SubmitNodeCollection, not an isolated one-off.

RenderSetup exposes a forceSolidModelPhase flag (set via .withForcedSolidModelPhase()) specifically meant to prevent RenderTypes that have GPU blending (hasBlending() == true) but no configured OIT pipelines from ever being routed into the OIT draw phase — used today by banner_pattern, wolf_armor_cracks, patterned_shield_glint, and trimmed_armor_glint.

However, of the three methods in SubmitNodeCollection that decide whether a submission goes to the solid phase or the translucent/OIT phase, only one respects this guard:

• submitModel(...) — correctly checks !renderType.forceSolidModelPhase() && renderType.hasBlending().

• submitBlockModel(...) — checks only renderType.hasBlending(), ignoring forceSolidModelPhase() entirely.

• submitMovingBlock(...) — doesn't consult the RenderType at all; it routes the entire multi-layer submission based on a single model-level flag (model.hasMaterialFlag(1)), even though the underlying draw buffer for that submission can contain quads of multiple distinct RenderTypes (solid_moving_block / cutout_moving_block / translucent_moving_block) built per-quad in MovingBlockFeatureRenderer.buildGroup. RenderTypeFeatureRenderer.executeGroup then calls drawFromBufferOit on every buffered draw in that group without re-checking each draw's own RenderType, which is exactly how solid_moving_block (which never gets .setOitPipelines(...) in RenderTypes.createMovingBlockSetup) ends up hitting PreparedRenderType.drawFromBufferOit's IllegalStateException.

Why this matters beyond MC-310235: if the fix for that ticket only patches submitMovingBlock's specific case (e.g. by special-casing moving blocks), submitBlockModel retains the identical missing check and would silently misroute any future (or currently unused) block RenderType that blends on GPU but lacks both OIT pipelines and forceSolidModelPhase — reproducing the same crash class through ordinary block rendering instead of piston-moved blocks, with no combination currently known to trigger it (which is likely why it hasn't surfaced in crash reports yet).

Suggested fix: centralize the "can this RenderType safely enter the OIT/translucent phase" check into one shared predicate (e.g. RenderType.canUseOitPhase() = hasBlending() && !forceSolidModelPhase()) and use it consistently in all three call sites, and make submitMovingBlock's phase decision per-quad/per-RenderType rather than per-whole-model.

Steps to reproduce: none provided — this is a source-level observation from the decompiled client, not an in-game reproduction. See MC-310235 for the one confirmed manifestation of this defect class.