[MG_Backend, MG_Pipe] (Disaggregated): P5e - throw both run-ahead constants (NOT FOR MERGE YET)

kMGPipeP5eRunAheadReady (MG_Backend/Init.cpp) and kMGPipeP5eClientWaitRuleLanded
(MG_Pipe/PipeApply.h) both to true. They are ONE switch with two spellings and the integration
commit throws both.

THIS BRANCH IS NOT MERGEABLE AS IT STANDS and is parked so the defect it exposes can be worked on
against a reproducible head. Measured on this commit:

  build rc=0 · unit 2254/2254 · gens rc=0 · flavours rc=0 (pull 915 TUs, push 929 TUs)
  integration-split   112 / 181   (69 failed)
  integration-gpu    1290 / 1359  (69 failed)

and the failures are FLAKY: 71 failed at -j 4, 68 at -j 1, and a single entry run alone passes and
then aborts on a repeat. A census over all 181 entries under each entry's own command and
ENVIRONMENT gives 70 red on 17 distinct <field>@<verb> pairs, over just FOUR fields:

  27  GetRenderStateParametersVersion
  25  GetTextureContextId
  16  GetBufferBindingSlot
   2  IsCapabilityEnabled

spread across eleven verbs - Clear, DrawArrays, DrawElements, DrawElementsBaseVertex,
DrawElementsIndirect, DrawElementsInstancedBaseVertex, EndTransformFeedback, GetIntegeri_v,
GetSyncStatus, MultiDrawElementsBaseVertex, ReadPixels. Several of those verbs are BARRIERED, which
is what makes this interesting: 16 of the 70 abort on the UNBARRIERED arm
(why=UNBARRIERED) and the other 54 are the plain unfresh-read abort with no [BARRIER-PULLED]
bracket at all, i.e. a RECORD-SUPPLIED field that the freshness stamp says was never filled.

One field at one verb, consistently, would be a missing migration. Four fields scattered over
eleven verbs, flaky run to run, including barriered ones, is a RACE - and the obvious candidate is
that gPipeInputs is shared mutable state whose mutual exclusion WAS the lockstep. The client still
fills it for barriered verbs while the apply thread is draining earlier unbarriered records, so the
client's fill and the server's verb-boundary stamp can now overlap in time. That is consistent with
P5d's own research conclusion, recorded in the roadmap, that retiring this barrier needs
gPipeInputs VERSIONING or double-buffering, deferred to P11 after P3b/P4b's handle-keyed twin
tables.

The strict lane being hard green (181/181, zero Fatal) is necessary and NOT sufficient, and this
commit is the proof: strict runs under lockstep, where ApplyOne stamps every record barriered, so it
cannot see anything that only happens when the client stops waiting. The lane measures remaining
DEBT; it does not measure whether run-ahead is correct.

MobileGL/MG_Backend/Init.cpp

@@ -95,7 +95,7 @@ namespace MobileGL::MG_Backend {
         // server into a run-ahead one, because the failure mode is not a slow frame - it is
         // the apply thread reading client memory that has already moved, which renders wrong
         // rather than aborting.
-        constexpr Bool kMGPipeP5eRunAheadReady = false;
+        constexpr Bool kMGPipeP5eRunAheadReady = true;
 
         // P5e (sb, ID-106). DirectGLES GAINS BIT 13 - the indexed buffer binding points - and
         // Magma deliberately does not. c0e landed the phase constant and the dirty-bit map with

MobileGL/MG_Pipe/PipeApply.h

@@ -992,7 +992,7 @@ namespace MobileGL::MG_Pipe {
     // Computing the predicate anyway (PipeApplier::ApplyOne) is deliberate: it keeps the
     // function exercised on every record for the whole phase rather than first run on the day
     // it starts deciding.
-    inline constexpr Bool kMGPipeP5eClientWaitRuleLanded = false;
+    inline constexpr Bool kMGPipeP5eClientWaitRuleLanded = true;
 
     // P5c (rv): the two serials the PipeInputs texture-shutter accessors answer with under a
     // server-stamped verb (FieldOwnership.def, APPLIER_DERIVED). Free functions rather than