Fix AB-BA memoize/TestAccess lock-order deadlock (sibling of #29)

[mansbernhardt]

Summary

Fixes an AB-BA deadlock between the context (hierarchy) lock and the TestAccess write lock on the memoize first-access path — the direct sibling of the 1.0.6 reduceHierarchy fix (#29), on the path #29 did not cover.

memoize's first-access setup takes the context lock B (context.lock { … }) and only then, through the nested Context.transaction, the TestAccess write lock A (acquireWriteLock()) — i.e. B→A. Every writer (Context._modify / Context.transaction) takes A→B (acquireWriteLock() before lock.lock()). Run concurrently, the two opposite orders deadlock:

• memoize thread — holds B (context lock), awaits A (TestAccess lock)
• writer thread — holds A (TestAccess lock), awaits B (context lock)

Reachable only under .modelTesting: the base ModelAccess.acquireWriteLock() is a no-op in production, so lock A doesn't exist there. It never wedges a shipping app — only the test plan.

How it was found

Captured live with sample on a hung xctest in a downstream consumer's macOS package test plan (122 suites, serial). The hang victim varied run-to-run — whichever model was mid-activation when the race landed — which is exactly why load-aimed mitigations (serial execution, build governors, timeout scaling) never cured it: a deadlock is immune to all of them. Three independent stack samples all showed:

• main thread: onActivate() → memoized child read → memoize first-access → context.lock (B held) → Context.transaction → TestAccess.acquireWriteLock() → blocked on A
• drain-executor model tasks: Context.transaction (A held) → lock → blocked on B

All threads __psynch_mutexwait, 100% of samples — a hard deadlock, not starvation.

Fix

Acquire the TestAccess write lock before the context lock in memoize's first-access block, matching the canonical A→B order that Context.transaction establishes. Both locks are recursive, so the nested Context.transaction's own acquireWriteLock/lock re-enter harmlessly. Locking-discipline change only — no behavior change, no-op outside .modelTesting.

Tests

• New: MemoizeLockOrderDeadlockTests — a concurrency smoke test (mirroring HierarchyLockOrderDeadlockTests): many leaves activate, each running a first-access memoize concurrently with sibling Context._modify writes; asserts each iteration settles. The narrow timing window means the deterministic guard is the downstream plan below.
• No regression: MemoizeThrashTests, MemoizeDirtyObservationTests, HierarchyLockOrderDeadlockTests (Fix AB-BA context/TestAccess lock deadlock in reduceHierarchy #29) all pass.
• Authoritative reproduction: the downstream macOS package plan (503 tests / 122 suites) hung ~every run before this fix (ran 3.5h until killed) and passes in ~5 min after — zero stalls.

---

Also in this PR — stabilize a pre-existing Linux-parallel flake

Adding the new suite increased Linux (parallel) load and reliably surfaced a pre-existing flake in the unrelated testForEachCancelPreviousInheritsContext (a test with a history of "Test stability fixes"). It asserted a cancelled forEach body's += value never runs, but did so by racing a fixed 100 ms wall-clock wait against a 500 ms work sleep — under load, >500 ms elapsed and the work completed first (processedCount → 1). Made deterministic following the repo's waitUntil convention: the work can now only finish via cancellation, the body records (in a @Locked flag) that it was interrupted before the write, and the test waitUntils that flag. Passes 5/5 locally (~0.017 s each).

Stability verified: CI green across 3 consecutive runs on this branch (run_attempt=3, all jobs incl. Linux parallel/serial, macOS parallel/serial, WASM, Android).