aarch64 strict gate: FCNTL_PM_CONTENTION_ORACLE fails to arm under host load (attempts=3, armed=0) - 2/40 boots at be412ee9

[ryanbreen]

[FCNTL_PM_CONTENTION_ORACLE:aarch64:attempts=3:armed=0:holder_cpu=u64::MAX:pm_busy_probe=0:calls=0:eagain=0:first_errno=u64::MAX:first_wait_us=0:hold_done=1:joined=1:FAIL]

[TEST:syscall:fcntl_pm_contention_oracle:FAIL:fcntl reported a contended process-manager lock to userspace]

Rate: 2/40 boots in the be412ee battery (boots 17 and 24, both at gate-internal concurrency 2)
Baseline: 0/60 in the 0b3b908 battery
Pinned by: PR #819

Failure Analysis:
The test marker indicates the peer never held the lock (calls=0), so the verdict text misdescribes the actual failure: nothing was reported to userspace; the lock acquisition never happened under concurrent load.

Serial Paths:

• /private/tmp/claude-501/-Users-wrb-fun-code-breenix/d69ffb9d-4539-4cf3-8a3d-a872ff7c830b/scratchpad/health-819-serials/strict-boot17-*.txt
• /private/tmp/claude-501/-Users-wrb-fun-code-breenix/d69ffb9d-4539-4cf3-8a3d-a872ff7c830b/scratchpad/health-819-serials/strict-boot24-*.txt

Related: #826 (host load), #819

[ryanbreen]

PR #838 merged to main at e9b0a4f6b45bea1ffddd9b26c674d350581e44c8
(merge commit; branch tip 2feaee92).

The fcntl process-manager contention oracle's arming is now a deadline
rendezvous instead of a fixed 8 ms hold with 3 polling attempts: the holder
publishes its hold with a release store and keeps it until the driver asks
for it back or its own 250 ms safety deadline fires, and the driver waits
under a 2 s deadline with preemption disabled before the hold can start.
The boolean armed/attempts marker is replaced by FcntlPmArm, 8 named
verdict arms each with its own tag and TestResult::Fail text, so an
arming failure no longer reports a false syscall-result sentence
(calls=0 under "fcntl reported a contended process-manager lock to
userspace", this issue's own symptom) -- it now names which rendezvous step
failed (hold_safety_release, arming_timeout, etc.) and carries
arm_wait_us/acquired/hold_safety instead of attempts.

Landing re-smoke ran the aarch64 strict gate 80 boots across two
origin/main merges (the branch's own review evidence covers 130 more).
Across the 210 boots, this issue's own signature
(attempts=3:armed=0:...calls=0:...FAIL) appears 0 times. One boot printed
a different, already-disclosed arming failure (hold_safety_release,
filed separately as #836, not repaired by this PR) and one unrelated red
was filed as #840 (a scheduler strand-injection timing miss in a subsystem
this PR does not touch). Full evidence, both landing merges' fixture
conflicts, and the disclosed limitations:
docs/planning/green-program/syscalls/819-ORACLE-ARMING-2026-09-05.md.

[ryanbreen]

Verified fixed by the merged evidence above.