fix: enforce bounded parallel test execution

Review threads live on the whole diff, not on one commit, so none are shown here - a thread's line means something in the branch's final form, and painting it into an intermediate step would put it on code it is not about.

README.mdmodified+19-0

Changes to README.md

		⋯145 linesShow the 145 lines above this hunk@@ -146,6 +146,25 @@ The accepted top-level sections are `test`, `parallel`, `reporter`, `snapshot`,
146	146	`watch`, `memory`, `ui`, and `coverage`. Options retain the same execution-mode
147	147	limitations as their CLI equivalents; unsupported combinations fail explicitly.
148	148
	149	+### Parallel execution semantics
	150	+
	151	+Programmatic runners can enable bounded execution with `RunnerOptions.parallel`
	152	+and set `n_jobs`. A configured value is the exact maximum number of active test
	153	+workers; omitting it uses the host's logical CPU count, with a one-worker
	154	+fallback when detection is unavailable.
	155	+
	156	+Suites and nested suites are visited in declaration order. `beforeAll` and
	157	+`afterAll` run once on the coordinating thread around that suite and its nested
	158	+suites. Direct tests within a suite may overlap. Their inherited `beforeEach`
	159	+and `afterEach` hooks run on the same worker as the test, so per-test hook order
	160	+is preserved but hooks from different tests may overlap. Hook state and the
	161	+allocator passed to tests must therefore be thread-safe.
	162	+
	163	+Reporter callbacks never run concurrently: test results are emitted in
	164	+declaration order after each parallel batch, making output and final totals
	165	+deterministic. A parallel batch is already scheduled as a unit, so `bail` cannot
	166	+cancel tests that have started.
	167	+
149	168	### Programmatic Mode
150	169
151	170	For more control, you can manually register tests: