fix(compile): one error assembly, cross-checked against IRIS's own count

[PYDuquesnoy]

iris_doc{mode:put, compile:true} was the third copy of the compile-console loop, and the #80 fix reached only two of them. Measured live before touching anything — IRIS 2026.1 (Build 235U), namespace APP, MCP 0.18.0 as shipped, Zz.MSG.Undercount (three methods, three undefined macros), the same class through both tools:

path	IRIS printed	we reported
iris_compile (the path #80 repaired)	Detected 13 errors	14 entries (13 + the status.errors wrapper)
iris_doc{mode:put, compile:true}	Detected 13 errors	1 entry

The one entry that survived was #5123 Unable to find entry point for method 'M1' — a cascade. ZzUndefined0/1/2, named plainly by IRIS on three console lines, never reached the response at all, and the response still carried the standard hint "Fix the first reported error and recompile — later errors are often cascades of the first", pointing the caller at the one line that was definitely not the cause.

Two faults, two fixes

The copy. Three sites assembled the same list from status.errors + console: iris_compile, IrisConnection::compile_document, and iris_doc's inline loop. #80 fixed two. The third could fall behind precisely because it was a copy — so it is no longer a copy. compile_error_list(body, console) is the single assembly for the string consumers, and it carries the diag_stands_in_for rule too, so the multi-line status wrapper stops swallowing the first method's own entry (N broken methods reporting N-1).

The missing check. IRIS computes Detected N errors itself; the number does not pass through our parser, so it is an independent check available on every compile, and no path used one. detected_error_count(console) reads it and every compile response now compares. When ours is short: errors_incomplete: true, errors_detected_by_iris, errors_reported, and a hint that replaces the cascade advice and names the field holding the rest. Wired at all four assembly sites — both iris_compile paths, iris_doc, and the CLI's compile_result_to_json.

The invariant is reported >= detected, not equality: the status.errors wrapper is an entry IRIS does not count (14 against 13 above, and that has to stay silent). Several tallies take the largest, never the sum, so an IRIS that printed per-item lines and a grand total could not manufacture a false undercount.

Verification

Wire test on this build, driving the MCP server over stdio, same class both times:

• fixed: compile_errors = 13, the three macros are the first three entries, no errors_incomplete — the cross-check stays silent on a complete list.
• parser deliberately reverted to the space-only prefix: compile_errors = 1, and the server itself returns errors_incomplete: true, errors_detected_by_iris: 13, errors_reported: 1, hint replaced. The silence above is a measured zero, not an untested path.

Three offline mutation controls, each caught: space-only prefix in the shared assembly (2 tests fail), note_error_undercount never flagging (2 fail), detected_error_count summing instead of taking the max (1 fails). The tests call the production assembly, not a copy of the loop, so a regression in doc.rs fails them.

Eight new tests, fixtured on the verbatim measured console.

Contract

New response fields on compile failures that undercount, and the iris_compile / iris_doc descriptions now say what errors_incomplete means — an agent that cannot see the field has no reason to read console. No version bump: 0.19.0 is on master and unreleased, so this folds into it.

Unrelated, found while running the pre-push gate and filed separately as #200: mcp_server_startup_latency_under_100ms fails about one run in five on an unmodified master.

Closes #199