@@ -72,6 +72,7 @@ My own earlier edits to `run_python.py` and `host.rs` (a later call's id, the ba
 - Round 1's CI (efe0835e), fix 2: mypy refused two lines of the predict bridge (an optional `request.payloads`, and `_answered` on any `Exception` after fix 1), fixed. python-core raised `UnsupportedRequestError` on `multicall.calls.101`, `entities.100001` and `forecast.batched` where the reference raises `StructuredDataError` under `UNSUPPORTED_REQUEST`: the host's error table keeps the reference's class for those three rules (`AS_THE_BASE_CLASS`), P1B-20 is back as the phase head holds it, and python-core's three baselines say so. The rust-host gate leg failed to compile because the gate overlays the checkpoint's `run_python.py`, `sdm-testkit`'s `case.rs` and `observation.rs` on the candidate, and `host.rs` reads the case fields `rows_per_call` and `fail_call` the checkpoint's `case.rs` lacks: the one commit carrying the case format (the test author's "the case format carries rows_per_call and the failed call": `case.schema.json`, `run_python.py`, `malformed-cases.json`, `case.rs`, `host.rs`) must land first as its own package, as T2.1g did. With the candidate's runner (that package landed), all 130 cases on DuckDB: `ratchet.py check --checkpoint 54b0d828` passes with the observations and `compare.py` with its expectations finds no difference; the two `s0.boundary.escape-*surrogate*` reports are T1.12's diagnostic cases under register PQL-1, as their case files say, not new.
 - The case format landed first as T2.1i (the orchestrator's split); on the rebase onto it the test author's case-format commit shrank to its `host.rs` hunk, kept as a `T2.8c:` commit. T2.1i's reviewer's note, fix 2: the test host sends `rows_per_call` as the Python host does (`as_python_sends`: `json.loads` then `json.dumps`; `"\u0033"` is `"3"`, `-0` is `0`, `1e400`, an infinity to Python, refused before the run as that host refuses it), with a unit test. Both gate legs pass against c8075715 (`gate.sh --run rust-host`, and `--run python-core,python-old --no-l0` with a test-ops wheel built from this head); `cargo test --workspace --no-fail-fast` passes (880).
 - Round 2's CI, fix 3: the `rust-host on SQLite` and cross-host steps hold rust-host to `ratchet.py effective`'s expectation, which on SQLite and Postgres is python-ref's line of the key (`refusal -`) moved only by a case outcome naming that key; P2G-1 named the bare keys alone, so the three endpoint-refusal cases failed there. P2G-1 now carries rust-host case outcomes for each `@sqlite` and `@postgres` key (register data, no judging file). The DuckDB contract job ran out of its 60 minutes in its tests step (35 to 40 minutes on the phase head's candidates): `test_t28c_multicall.py`, run whole on one worker (`--dist loadfile`), observes python-core on `multicall.entities.100000@sqlite` twice, about 9 minutes each, since the case's `users` table (`CREATE TABLE ... AS`, no key) leaves SQLite's per-entity lookups (`COUNT(*)` and `LIMIT 1` subqueries, the reference's own statements) a full scan of 100,101 rows each. The same case with `user_id` a primary key, which the contract loader carries into SQLite and Postgres as an index, takes 3.7 s in place of 564 s and still gathers 100,000 entities in 10 calls: the case files are the test author's (asked of the orchestrator).
+- Round 2's CI again (bdbbfaac), fix 4: both 60-minute jobs ran out, with no one test stuck but every tool that loads the cases slower. `run_python.py`'s `_invalid` had jsonschema walk each item of the two 100,000-entity cases' index lists, about 0.9 s a case, on every load of the corpus (1.76 s against the phase head's 0.10 s), and `test_runners.py`'s S0 test loads the corpus once per observation (353 s against 76 s); a python-core observation of `entities.100000` took 0.75 s to validate, on each comparison. The fix is the judging package T2.1l (the orchestrator's), which this lane now sits on: the validator checks a long index list's items past its leading eight in plain Python by the list's own rule and has jsonschema see the document with the list cut, any document refused that way validated whole, so results are unchanged (the test author's test compares with a frozen copy of the old loader over every case and every malformed-cases change). With it the corpus loads in 0.24 s, an observation of 100,000 entities validates in 0.05 s, `ratchet.py check` takes 4.8 s in place of 6.8 s, and the S0 test 134 s. What remains is the runners' own work on the 21 cases, mostly the reference's and the core's 100,000-entity and 100-call runs, which the cases exist to test.
 
 ## Deviations and what is left