Compare range-element parents under NFC

[imnasnainaec]

Devin review: https://app.devin.ai/review/sillsdev/python-sil-lift/pull/28

Fixes #14. Fixes #27.

The range-parent check compared a range-element's parent against its siblings'
ids as exact strings. FLEx writes those two attributes with different Unicode
normalization — the grammatical-info and lexical-relation range-element ids
bypass its normalizing helper and come out NFD, while the parent attribute on the
same element goes through it and comes out NFC — so a sound parent link in a real
export was reported as an error. #14 reports this from a Sena export, #27 from
Sango; they are the same defect, and #27 adds the exporter-side mechanism.

What changes

One policy for resolving a name to an id. Every name that reaches a range or a
range-element now resolves the same way: by its exact spelling first, then under NFC.
That covers parent links, range values, and — new here — the name that keys a range
at all, a trait name or a header range id. Only undefined-range-value normalized
before, which is why one encoding split was an error in one check and invisible in
another. A range whose own id FLEx wrote in NFD was worse than invisible: the NFC trait
names keyed on it never found it, so every value in it went unchecked, an unresolved
name being indistinguishable from a trait no range defines.

A resolution that needed normalizing is reported, not swallowed. Suppressing the
false error alone would hide a real property of the data: sil-lift never rewrites the
ids (fidelity), so a consumer comparing raw strings still fails to resolve those
references, and nothing else would tell the user. New normalization-mismatch
warning — once per id however many references differ, for range ids and
range-element ids alike, naming both spellings by code point ('Comple\u0301ments' vs
'Compl\u00e9ments') because they render identically. range-parent stays an error
for a parent no sibling defines in any normalization.

Findings about a range are addressed to the file that defines it. Both the mismatch
warning and range-parent now report against the companion holding the element, rather
than one of them naming the .lift that merely references it. Header range ids are
resolved before the dangling-href check rather than inside it, so whether a header id
and a companion's own id agree is answered for a lexicon held in memory too, not only
one read from disk.

The prose said something the corpus doesn't support. Three sites and the changelog
described the .lift as NFC and the .lift-ranges as NFD. The normalizer is applied
per write, not per file: in sango.lift-ranges every label, abbrev, description and
every parent is NFC, and so are the semantic-domain-ddp4, translation-type, and
usage-type ids. Rewritten to name the mechanism, with the new warning documented in
the module docstring's list of semantic checks, the FLEx-output policy section, and the
exporter guide.

Coverage. A hand-authored negative/nfd-range-ids.lift + .lift-ranges pair
carries the shape end to end — NFD ids, NFC parents and grammatical-info value, one
parent that dangles in every normalization — asserting one error, one deduplicated
warning, and byte-identical save of both files, since normalization belongs to the
comparison and not to what gets written. In-memory regressions cover the range-keying
name, the header id, and a range holding one name in two normalizations, where each
reference must resolve to the sibling it matches exactly. PROVENANCE.md records what
is NFD and what is NFC in the Sango fixture.

Each range's id lookup is built once and read by the value checks, which rebuilt it
per trait before: Sango's semantic pass drops from 1.54s to 0.84s over the same
findings.

Effect on the corpus

	before	after
sango.lift range-parent	2 errors	none
sango.lift normalization-mismatch	—	6 warnings — 82 references reaching 5 ids, one of them under both aliases of the POS list
sango.lift undefined-range-value	1 (prenom)	1 (prenom)
AllFLExFields, all other fixtures	—	no new findings

Deliberately not changed

The dangling-ref sweep #14 asks for came up empty: all 7 findings in the corpus
(negative/dangling-ref.lift, spec-examples/0.13/{fields any order,hugal-ideal,
lexical-relations}.lift) are ASCII and none resolve under NFC, so entry ids and
relation/@ref keep comparing exactly. duplicate-guid compares guids, ASCII by
construction. Neither gets a normalization pass without a case to justify it.

Verification

ruff check, ruff format --check, mypy, and the full suite (543 passed).

Recommendations for the upstream FieldWorks exporter — including a separate, more
serious escaping gap on the morph-type id — are in a comment on #27, and are now
carried by sillsdev/FieldWorks#1063.

---

This change is