Two redundancies, both measured, both on the modern reader's per-test path —
the axis `docs/reader-performance.md` identifies as dominant at ~115 ms per
test case.

**Every query went through `xcrun`.** `xcrun` resolves a tool and execs it, so
routing each query through it spawned an entire extra process: ~35 ms via
`xcrun` against ~28 ms direct, n=20 warm. The answer cannot change within a
run, so resolve it once and invoke the tool directly, keeping `xcrun` as the
fallback when `--find` fails (no Xcode selected, Command Line Tools-only). The
lookup still goes through `xcrun --find`, so `xcode-select` and `DEVELOPER_DIR`
keep choosing the toolchain.

**A repeated test was queried once per repetition.** `parseTestCase` asked for
activities once per repetition with the same identifier, and each call spawned
a subprocess, fetched the whole document, and kept a single `testRuns` index —
so `RetryResults` made 6 queries for 4 tests. The spawn count was the sum of
repetitions, not the number of test cases, which puts every run using
`-retry-tests-on-failure` on the wrong side of it. `ActivitiesDocumentCache`
holds the document per identifier for the life of one read.

One deliberate behaviour change: a failed activities query used to record one
fault per repetition and now records one per test. It still reaches
`summary.faults` and still drives exit 3 — it is simply no longer counted once
for every retry.

Measured end to end, `--result-reader modern`, n=10:

    RetryResults  (4 tests, 2 repeated)   1,165 ms -> 984 ms   -15.5%
    TestResults   (21 tests, no repeats)  2,761 ms -> 2,671 ms   -3.3%

`TestResults` isolates the `xcrun` change. Note `--result-reader auto` still
prefers legacy while the toolchain offers the `--legacy` commands, so these
land in full when that changes — the event #391 exists to prepare for.

Also adds the probe for the one lead that could remove the per-test subprocess
rather than shrink it: reading the bundle's private `database.sqlite3`.
`scripts/capture_xcresult_schema.py` records what a bundle says about itself
and `xcresult-schema-probe.yml` runs it under two Xcode majors, because the
gating question is whether anything in the bundle reports a schema change.
Nothing obvious does: `user_version` and `application_id` are 0, and the
`DeveloperTools` table models the producing Xcode and is empty.

Two findings from building it, both recorded in the doc. `xcresulttool` is a
statically linked executable whose only non-system dependency is `libsqlite3` —
there is no framework to link, so in-process use is not available at any risk
level. And Apple emits column order nondeterministically, so any such reader
must address columns by name, and a fingerprint must sort them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…s question

Three findings from review, all valid.

**`DeveloperTools` values were filed under the wrong keys.** `table_columns`
returns columns sorted by name — it has to, because Apple's physical column
order is nondeterministic — but `developer_tools` paired those sorted names
with a `SELECT *` row, which yields *physical* order. Where the two disagree,
`zip` files each value under whichever key sorts into its position: the probe
would have reported the Xcode version as the build version, a wrong answer to
the single question it exists to ask. The existing test passed only by
coincidence, since `xcodeBuildVersion` happens to be both first-declared and
first-alphabetically. Now the projection names the columns, so physical order
never enters into it, and a regression test declares them reversed.

**The probe never actually compared its two legs.** Each matrix job could see
only its own capture, so the comparative question was left to be reconstructed
by hand from two artifacts. `scripts/compare_xcresult_schemas.py` states the
verdict directly, and a `compare` job runs it over both captures.

Its three outcomes are the point:

    fingerprint same                     -> INCONCLUSIVE
    fingerprint differs, version differs -> GATE AVAILABLE
    fingerprint differs, version same    -> NO GATE

`INCONCLUSIVE` is deliberately not spelled "no drift". A run where the schema
did not change proves nothing about whether a change would be detectable, and
reporting it as clean would be read as reporting it as safe.

**MD040.** The module-list fence now declares `text`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review question: what does the caching do to memory? It was a fair question
with no answer, because I had not measured it.

Measured now, and at fixture scale the difference is **within noise** — peak
RSS 24.8 MB before, 24.9 MB with the cache, 25.2 MB with this change, across 21
tests. So this is not a demonstrated regression.

The shape was still wrong. `ActivitiesDocumentCache` was keyed by test
identifier and lived for the whole read, so it retained every test's decoded
document to the end — O(tests) — when every query for a given test happens
inside a single `parseTestCase` call and O(1) does the same job. At 1,000 tests
that is roughly 1.5 MB of raw JSON plus decoding overhead against a 203 MB
baseline: not alarming, but growth that buys nothing, in a tool that has had an
out-of-memory bug (#337) and keeps `DownsizeMemoryTests` to pin it.

So the document is now fetched once in `parseTestCase` and passed down to each
repetition. The cache type, its dictionary and its lock are gone, and
unbounded retention is impossible by construction rather than prevented by a
test that fixture-scale noise could not have caught anyway.

The speed win is entirely preserved — `RetryResults` 963 ms with the cache,
962 ms with the local — and `ReaderSubprocessEconomyTests` still pins the
contract that made the cache worth having: one query per test however many
repetitions, every test still queried, each repetition keeping its own
activities.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The doc reported the two changes measured together, which made lead 1 look like
it helped `RetryResults` and lead 2 look like it helped `TestResults`. Neither
is true, and the combined figures hid that they scale on different axes.

Re-measured with a build carrying each change alone (n=30, alternating order,
separate output directories, both builds verified to emit byte-identical
reports):

    lead 1, dropping xcrun   TestResults   2,791 -> 2,653 ms   -4.9%
                             RetryResults  1,167 -> 1,166 ms   noise
    lead 2, fetch once       RetryResults  1,163 ->   964 ms  -17.1%
                             TestResults   2,656 -> 2,648 ms   noise

Lead 1 scales with total calls, lead 2 with repetitions. A run without
`-retry-tests-on-failure` gains nothing from lead 2, which the combined numbers
did not say.

Also records a discrepancy rather than smoothing it over: that 198 ms comes from
removing exactly two calls that measure ~34 ms each standalone, so a call inside
a real run costs about 3× what the per-call table predicts. Two explanations
were tested and both failed — the bundle is not read twice (one `read()` call
site, query count confirmed 6->4 through a wrapping client), and spawn cost does
not scale with the parent's footprint (29.3 ms from a ~30 MB parent against
30.3 ms from a ~330 MB one). No verified cause.

The per-call table is now labelled a lower bound, and lead 3 says not to
estimate the parallelism win from it — an estimate built on a figure wrong by an
unbounded factor is worse than admitting the number is unknown. Lead 3 also now
notes that leads 1 and 2 have already taken some of its headroom: a call that no
longer happens is a call there is nothing left to overlap.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review finding: `verdict` returns INCONCLUSIVE when one capture's bundles
disagree, and nothing exercised it. Correct — `write_capture` builds
single-bundle captures, so `one()` never returned None and the guard was dead
as far as the suite was concerned.

The suggested repro would not have reached it: two captures sharing a version
with different fingerprints is a genuine cross-toolchain result, and since
b7e34ac that is NO GATE, which is right. The uncovered branch needs a *single*
capture contradicting itself, so the new helper builds one with two bundles and
two fingerprints.

The distinction is the point. Two toolchains disagreeing is a finding. One
toolchain disagreeing with itself means the capture measured something other
than the schema — bundle-specific state, a half-generated fixture — and any
cross-toolchain conclusion drawn from it would be a real-looking verdict
invented from a broken measurement. All four fixtures on Xcode 26.2 produce an
identical fingerprint, which is what makes self-disagreement suspicious rather
than expected.

The test characterises behaviour that already worked, so it passed on arrival
and proves nothing by itself. Verified by negative control instead: with the
guard removed it is the only test that fails.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>