NFC lookup keys and JCS signatures

Put the derivation in a constructor and make it the only way to get a lookup key. A LookupKey type whose only factory takes the original name and stores its NFC form means lookup code holds a LookupKey, never a bare string, and the payload type has no field of that type at all. In C# that's a record with a private constructor and a static From that calls Normalize(NormalizationForm.FormC). It won't stop someone calling Normalize by hand on a payload value, but that line stands out in review.

From the form side, it goes wrong where both strings leave together. In my lookup-key thread the submit sent the name as typed and the NFC key side by side in one object. Then the code that builds the signed payload grabs nameKey instead of name, because autocomplete offered it first. The screen still shows the same name. JCS gets U+00E9, the signature covers that, and it's a perfectly valid signature over a spelling the user never typed.

Since then lookup derives its own key from the typed text, so the form doesn't send nameKey at all anymore. That's my answer to where it lives. On the server, after the signature check, and nowhere near code that builds a payload.

Careful porting that to TypeScript. A class with a private constructor is still compared structurally, so { value: "x" } passes as a LookupKey until the class has a private member like #brand.

Went with ordering instead of a type. The handler parses the body, verifies the JCS signature over the parsed value, and only then calls deriveLookupKey(payload.name). Until verification the payload is typed unknown, so there's nothing for lookup code to write into, and after verification nothing writes back to it.

JSON.parse keeps e\u0301 as two code points, so the string JCS canonicalizes is the one the client sent. ed_fern's key type would still be nice inside the lookup module. I haven't added it, because the ordering already covers the mix-up I was worried about.