[novoj]

Closes #47. § 1–3 landed in #52. This PR is § 4: the deterministic barrier tests and the remaining live cases.

Barrier tests (SuspensionRaceBarrierTest)

Each test runs the competing action inside the mocked JDI call that marks its gap, on the thread the dispatcher, the watchdog or a job would run it on. Every run therefore takes the same interleaving, and every scenario ends on the suspend counts the target would really have (FakeSuspendModel).

Gap	On the old code	Outcome
A job still compiling → a frame tool	passed	none needed: a job counts from its start
A frame tool reserved and checked the thread → the dispatcher leases it	failed: invoked code ran under the tool	lease() waits while a frame tool reserves the thread (at most 2 s, then refused)
The hold check → a frame tool's retry	failed: jdwp_set_local wrote into the frame of the thread's next stop	a retry needs a hold only a tool ends: a published stop or a manual hold (userHoldsOn)
The watchdog's owner query → the owner leaves and stops at a new breakpoint	passed	none needed: unblock re-checks the owner
A job's compilation → its stop released and replaced	passed	none needed: the lease is refused

There are also two more tests: a positive control showing that a published stop still vouches for a retry, and a check that a frame tool which never finishes makes the lease refuse after the wait.

Live cases (SuspensionOwnershipLiveTest)

• New: a stop-all released while its evaluation outlives the tool's wait. The other threads run at once; the evaluating thread runs once the evaluation ends. Passed.
• New: the watchdog cancels a queued thread stop, then that thread stops again. The new stop keeps its own suspension. This case found the third race. JDWP shows a thread that invokes from inside its event's handling as RUNNING even while it waits for a monitor, so the watchdog never looked at it. A thread shown running is now asked for its contended monitor too; one that really runs reports none (unit test in SuspensionWatchdogTest).
• Already present (from fix: 2.11.0 test-flight findings — probe hits read at exit, probes wait for their class, clearer replies, hint-free flights #52): reset during an evaluation, co-delivered arming, and disconnect during an evaluation that never returns.
• Test fix: enableSuspended(request, thread) suspends only the request's filter thread. The VM-wide variant could invalidate the frame of an evaluation in flight ("Thread has been resumed"). That made Order 1 flaky; it failed in one run.

Tests

• Unit: 1391 tests, 0 failures. The 45 skipped are the opt-in live tests.
• Race, session, watchdog and listener tests on a single core (taskset -c 0): 196 tests, 0 failures; looped 6× before the watchdog fix.
• SuspensionOwnershipLiveTest: 3 of 3 full-class runs green.
• All live suites: 42 tests, 0 failures.

Docs: docs/event-pipeline.md § 14, docs/threading-and-safety.md § 5, docs/testing.md.