The profile editor writes what Plaza reads

[sepehr-safari]

Closes #263.

Plaza reads nine keys off a kind:0 and the sheet offered three, so four could be displayed and never entered.

The one with a consequence is lud16. It is how NIP-57 finds somebody LNURL callback, so an account set up only in Plaza could not be zapped by anyone, in any client, until its owner opened something else. Website, banner and the NIP-05 identifier are the same gap with smaller stakes.

now editable	validated as
Website, Banner	starts with a scheme
Lightning address	name@domain.tld
NIP-05 identifier	name@domain.tld

The merge is untouched, which is the point

profileMergeBase already reads the raw published record rather than the parsed cache, an emptied field removes its key rather than writing "", a value too long to be shown is never written, and the write refuses outright when the existing record will not parse. Adding fields is adding setOrRemove calls and the seeding to match.

Seeding is the half that matters. The merge publishes what the model holds, so a field shown in the sheet but never seeded would go out as absent and delete the key. profile_can_save makes that unreachable: it refuses every stage where the profile has not been read, and the one stage where absent really is absent is a key minted here. There is a test asserting every shown field is seeded, because that is the invariant the whole thing rests on.

Validation stops where honesty stops

Shape only. Whether a lightning address has an endpoint behind it cannot be known without asking, and a checker that refused an unusual but working URL would be worse than one that let a typo through: the reader can see their own picture failing to load, and cannot see why this app declined to save it. Empty is always allowed, because an empty field removes its key and that is somebody saying they do not have one.

Saving is refused while a field is unusable and the sheet says which. A kind:0 is replaceable, so a bad value is not a private mistake.

Tests

651 to 655, and I checked all four are load bearing by sabotaging the two halves separately. Making the validator report everything fine fails the two validation tests; dropping the lud16 write fails the two merge tests.

My first sabotage disabled only the picture check and failed nothing. That is precisely the false pass this kind of check exists to catch, so it is worth saying that it caught me.

Three existing tests changed. They used lud16 and nip05 as the canary for "a key this app does not model", which is what this PR stops being true. They now use pronouns and lud06, which it still cannot see.

Not here

No version bump. The plan put it on this PR, but Plaza has already shipped through v0.23.0 and another item is still to come, so what the next release is called is your call rather than an increment.