[MG_Pipe, MG_Test, CI] (Disaggregated): P5e ID-125 - admission gains the retiring-phase disjunct

- ID-116's static rule failed on a row no package in this phase may touch. pa retired the
  per-draw program pull, which unmasked GetTransformFeedbackProgram@DrawArrays (11 entries):
  BARRIER_PULLED, on kWaitNone draw_vbo, and ruled out of P5e entirely by CONTRACT-P5E section
  5.7, with a retiring phase of "P3b/P4b (Espryt), P7 (Magma)". The rule was wrong, not the code.
- A pull is now admitted if the field is BARRIER_PULLED, the verb has a stamp row, the field is
  in the verb class's may-read mask, and EITHER the verb's op is statically barriered OR the
  field's retiring phase does not name P5e. This table is only ever consulted on a record the
  server already stamped BARRIERED - CountBarrierPull's unbarriered arm is [[noreturn]] and
  fires first - so the pull is legal by construction and the only open question is whose debt it
  is. The retiring-phase column is exactly that answer and was already in the table.
- A verb with NO stamp row still admits nothing under either disjunct: the server stamps only
  MGP_VERB_OP_LIST's ops, so any other bit would be a row nothing can exercise. 111 -> 174 pairs.
- The phase column is matched as a TOKEN, not a substring, so a "P5" or a future "P5e2" cannot
  answer for "P5e".
- All six of ID-125's survivors checked: GetFramebufferBindingSlot@ReadPixels and
  GetTextureUnitObject@CopyTexImage2D by disjunct 1; GetTransformFeedbackProgram@DrawArrays
  (P3b/P4b), GetTextureObject@CopyImageSubData (P7) and ValidateProgramName@ShaderStorageBlockBinding
  (P9) by disjunct 2. GetTextureObject@CopyImageSubData holds by BOTH, asserted separately.
  GetProgramForDraw@DrawArrays, GetBoundVertexArray@DrawArrays and
  GetProgramForDispatch@DispatchCompute stay rejected.
- Magma's GetFramebufferBindingSlot@Clear is NOT admitted and cannot be: the retiring-phase
  column is one string for both backends and it names P5e for Espryt. The DirectVulkan entries
  get their own lane label instead (item 7), which keeps the Espryt allowlist about Espryt.
- StrictErrorsAlsoPromotesTheStickyForwards is RENAMED to
  StrictErrorsReachTheStickyForwardsAndNameThemByField and restated. Not one of the seven sticky
  forwards names P5e (P7, P7/P9, P7/P13, P9), so on a stamped verb they are all admitted now.
  The claim that still has teeth is that the detector REACHES them - asserted by rsp moving and
  by the marker naming the field and its phase, so "did not abort" cannot pass for "never
  detected". The Fatal half keeps its own case next door on GetBoundVertexArray, a P5e row.
- Six new derivation controls, including one that makes GetTransformFeedbackProgram this phase's
  debt and requires it to leave the unbarriered verb's allowlist - without which disjunct 2
  could be a constant `true` and every other control would still hold.

.github/workflows/test.yml

@@ -1254,10 +1254,17 @@ jobs:
           # nothing made safe, because resource_copy_region is kWaitNone. Neither error is
           # visible by reading the list; both are obvious the moment the list is DERIVED.
           #
-          # The rule is ID-84 said in tables that already exist: a <field>@<verb> pull is
-          # admitted iff the field's ownership row is BARRIER_PULLED, the verb's wire op is
-          # statically barriered (kMGPipeWaitClasses != kWaitNone, i.e. the client really is
-          # parked behind the record) and the field is inside the verb class's may-read mask.
+          # The rule is ID-84 said in tables that already exist (ID-116, refined by ID-125): a
+          # <field>@<verb> pull is admitted iff the field's ownership row is BARRIER_PULLED, the
+          # verb has a stamp row, the field is inside the verb class's may-read mask, and EITHER
+          # the verb's wire op is statically barriered (kMGPipeWaitClasses != kWaitNone, i.e. the
+          # client really is parked behind the record) OR the field's retiring phase does not
+          # name P5e. The second disjunct is the honest reading of ID-84: this comparison only
+          # ever sees pulls on records the server stamped BARRIERED - an unbarriered one aborts
+          # before any of this - so the pull is legal by construction and the only question left
+          # is whether THIS phase still owes the migration. Without it the lane would go red on
+          # GetTransformFeedbackProgram@DrawArrays, a row CONTRACT-P5E §5.7 rules out of P5e
+          # entirely and no package here is allowed to touch.
           # `--print-admitted` prints exactly the table MGPipeBarrierPullAdmitted() answers
           # from, so this shell and the C++ cannot drift: retiring a verb's wait class narrows
           # the lane with no edit here, and a new BARRIER_PULLED row widens it only on verbs