test(#323): state the grain contract as behaviour, not as names

[ligon]

Companion to #635. That PR pins the wiring; this one pins the behaviour.

Why a behavioural suite

The D1 guard is a static scan. It can prove core does not import or call the country-facing reducers — and nothing beyond that. A locally-defined helper of any name could reduce grain silently and pass it. That limit is not hypothetical: the scan was a substring grep, and it held development red for a week by flagging country._collapse_to_cluster_grain, a legitimate private helper that merely shared a suffix.

So state the contract as properties of what core returns. Crucially, the contract is not "core never reduces rows" — Site 2’s household→cluster projection legitimately reduces:

	property
P1	Conservation — output is exactly the distinct declared keys. General in a way a name-check cannot be: it does not care where a row was dropped, so a future site breaks it whatever it is called.
P2	No fabrication — every returned row existed, verbatim, in the input.
P3	Asymmetry — destructive collapse is loud; lossless collapse is silent.
P4	Accuracy — the reported count matches an independent oracle.

P3’s silent half is load-bearing. 6.46M of the corpus’s ~7.5M duplicate rows are exact duplicates, so warning on the raw count would bury the ~542k real losses — and a warning nobody reads is how this bug survived being closed once already.

P4’s oracle is written from the design note’s definition, not from core’s implementation, so it cannot pass by agreeing with a bug in the thing it checks. And test_p4_a_vacuous_report_would_not_satisfy_this_file guards the guard — P1/P4 would pass trivially if core simply stopped reporting.

P2 fails today, and that is the point

Marked xfail(strict=True): CI stays green, the defect is on the record, and the ratchet cannot be forgotten — the moment core stops fabricating, the test XPASSes and strict turns that into a failure.

groupby().first() takes the first non-null value per column, so complementary rows yield a row that never existed:

(a1, <NA>) + (<NA>, b2)   ->   (a1, b2)

Verified against the real core path. It is reported (DESTROYED 1 of 2), so this is not a silent-loss bug — but what core returns is synthetic, which is worse than dropping a row.

The asymmetry in how this is described is worth a look:

• Site 2 (fix(#323) Site 2: the cluster collapse #614 cannot see — 17 countries, 53,199 rows destroyed #617) names it exactly: "a conflicting cluster does not even yield one of its households’ rows, it yields a COMPOSITE."
• Site 1 (fix(#323): close the grain-collapse CLASS — audit before collapse, persist the signal through the cache #614) does not. It says "These rows are gone from the returned data" — which reads as though the survivor is one of the real rows. It is not.

Same defect; reported honestly at one site and misleadingly at the other. No static check of any kind can see either.

Also pinned

The sanctioned exception. _ADDITIVE_MEASURE_COLUMNS (food_acquired) sums rather than selects, so P2 does not apply and conservation of the total replaces it — otherwise the additive path is the one place in core with no stated contract.

Result

13 passed, 1 xfailed. Tests only; no lsms_library/*.py touched.