test(seal): prove the xml-sec fork on Italy and France

[LKSNDRTMLKV]

Closes #302. Stacked on #316; retarget as that merges.

just check is green (1132/1132).

What the fork is for, now demonstrated

The published xml-sec caps XML node-sets at 65 536 entries. A real list over that ceiling now verifies in a_list_over_the_unpatched_ceiling_verifies_with_the_fork, confirmed by removing the [patch.crates-io] stanza and watching it fail with

node-set entries exceeds policy maximum 65536: got 65540

The documents are deliberately not committed. They are ~5 MB of XML; they live under tests/fixtures/local/ (git-ignored) with a README saying how to fetch them, and the test skips loudly when they are absent so a checkout without them reads as "not demonstrated here" rather than as a pass.

That is acceptable because the regression guard does not depend on them. the_patched_xml_sec_is_the_one_that_resolved reads the resolved source out of Cargo.lock and runs everywhere. It catches the failure that actually bites: [patch.crates-io] applies only while the fork's version satisfies the requirement, and bumping past it — what someone will do the day upstream publishes — makes Cargo emit an unused patch warning, not an error and fall through to the registry crate.

Editing Cargo.lock does not reproduce that, which is the first thing anyone will try: Cargo reconciles the lock against the manifest before building and rewrites the edit away. The assertion was confirmed by inverting it instead.

"Only Italy and France" was already false

#302 records a measurement from 2026-09-11. Re-measured across every list the LOTL points at on 2026-09-15:

	bytes	node-set entries	without the fork	with the fork
FR	2 545 157	65 541	fails	verifies
CZ	2 630 805	65 543	fails	verifies
IT	2 855 744	65 540	fails	verifies
ES	3 027 766	65 543	fails	verifies
DE	5 355 449	—	fails	still fails

Four lists need the fork, not two — Czechia and Spain have crossed since. Byte size does not predict the count, so this is a measurement rather than a rule, and it grows.

Germany does not verify at all, on a different ceiling the fork never touched: XML nodes exceeds policy maximum 100000: got 100001. One node over. Upstream structured-world/xml-sec#158 is about the node-set constant and would not close it. Filed separately.

The test therefore demonstrates the mechanism rather than enumerating the members, and says so.

The fetch cap contradicted the fork

#302 asked that the 1 MiB cap be re-checked "rather than assumed to cover them". It did not cover them, by a wide margin — fetch_trusted_list refused every document over 1 MiB, so the fork's purpose was unreachable through this crate's own fetch path. Nothing noticed: the chain tests read fixtures and never call the fetcher, and the cap was asserted nowhere.

The first fix for this was also wrong and is worth recording. I set it to 4 MiB from the fixtures I happened to have committed — which is the original mistake with a different sample, one commit after describing that mistake. Germany is 5.11 MiB.

It is now 8 MiB, sized against the whole measured set, and the invariant is a compile-time assertion beside the constant rather than a test:

const _: () = assert!(MAX_TRUSTED_LIST_BYTES >= LARGEST_PUBLISHED_LIST_BYTES, "…");

A relationship between two constants should not produce a binary when violated. Confirmed by setting the cap back to 1 MiB and watching the build fail with the message.

LARGEST_PUBLISHED_LIST_BYTES is a dated measurement, and its comment says so: nothing here can re-derive it without fetching thirty documents from thirty Member States.

One thing that looks alarming and is not

Committing a signed XML document changes its bytes — .gitattributes normalises line endings, and Italy arrives with CRLF. It still verifies, checked rather than reasoned about: the fixture was deleted, restored from the index, and re-verified. XML parsing normalises end-of-line before canonicalisation, so the signature never sees the difference.

That mattered while the documents were committed. It no longer applies to them, but it applies to the LOTL fixture beside them, which has been LF since it was added.