Keep parent-history locks within the run during concurrent child completion #1142

Concurrent service child completions can deadlock on MariaDB while deciding whether to wake their parent barrier. One transaction holds the parent run and requests its history with FOR UPDATE. The optimizer can use a primary/table scan, encountering an uncommitted sibling history row whose transaction is waiting for that same parent run.

The complete default-MariaDB timer-correction gate reproduces this independently of Saga: accepted-main-based timer source f494 reports one failure in V2ServiceModeParallelChildBarrierTest::testConcurrentChildCompletionsSerializeOneBarrierWakeOnParentRun (404 cases / 5,158 assertions in shard 0). The earlier Saga backend investigation observed and corrected the same lock cycle. Its small generic fix is currently part of the unreleased foundation source and should be separated so ordinary core users do not wait for Saga.

Use the existing per-run sequence index for the locking parent-history read on MySQL/MariaDB, preserving current-read visibility, parent serialization and configured connection/table/index prefixes. Keep other drivers unchanged. Strengthen the existing two-writer barrier control to retain both uncommitted child history rows before parent resolution and discriminate the original lock cycle. Preserve one parent wake and both child outcomes without adding retries, external work under locks, or a new index.

Acceptance includes predecessor failure / successor pass, affected MySQL and default-MariaDB cases, full normal quality, and the complete backend inventory on the composition with #1139/#1140. Keep the original failed attempts distinct. This is a core correction independent of Saga, with no package or retired PHP Server release included. Related #892, #1063.